Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 6/2/2017 #16414

Closed
DanielRosenwasser opened this issue Jun 9, 2017 · 0 comments
Closed

Design Meeting Notes, 6/2/2017 #16414

DanielRosenwasser opened this issue Jun 9, 2017 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Propagated Inference for Uninstantiated (Free) Type Parameters (#9366)

function compose<A, B, C>(f: (x: A) => B, g: (y: B) => C): (x: A) => C {
    // ...
}

let boxElements: (a: string) => { value: string[] } =
    compose(x => [x], y => { value: y });

Currently this works.

Now we ask, what if we wanted boxElements to operate on any type?

function compose<A, B, C>(f: (x: A) => B, g: (y: B) => C): (x: A) => C {
    // ...
}

let boxElements: <T>(a: T) => { value: T[] } =
    compose(x => [x], y => { value: y });

Currently this doesn't work well - when we get the contextual type for x, we get it from the erased signature of <T>(a: T) => { value: T[] }, which is really just (a: any) => { value: any[] }.

We will have a PR that will help fix this.

Q: What about constraints?
A: Constraints will be carried through.

We will still have some problems with compositional patterns without explicit types.
For example:

declare function compose<A, B, C>(f: (x: A) => B, g: (y: B) => C): (x: A) => C;
declare function box<T>(x: T): { value: T };
declare function list<U>(x: U): U[];

compose(list, box);

The problem is that TypeScript draws the following inferences:

Type Parameter Inferences
A U
B U[], T
C { value: T }

The way we walk through arguments (simple and left-to-right) and draw inferences simply isn't sufficient - we need to find a way to unify these type parameters.

But it's not just a matter of throwing unification at the type system. So the current question is how do we introduce some unification to the current process. Perhaps it will be a "last resort" process. And this will be exploratory work.

@gcnew did do great work, but pointed out many of the difficulties and roadblocks you can run into.

Changing default target to ES5

  • Very strange that we wouldn't simply move the the higher one?
  • Why take a breaking change when we'll need to make another breaking change in the future?
  • Are there a lot of people running into this problem?
    • Doesn't appear that a lot of people have been complaining about it.

Pure annotation in downlevel emits

  • Currently, Uglify doesn't understand when our class emit.
    • It would be great if Uglify could operate on the ES2015 code.
  • We just want to tell other tools it's a class - onus of determining side-effects being on TypeScript is probably more questionable than an optimizer doing so.
  • Decision: emit JSDoc @class comment unconditionally.

Lib reference directive (#15780)

  • /// <reference lib="name" />

  • Problem: things like corejs on DefinitelyTyped conflict with compiler defaults.

  • This means could simply be reduced to /// <reference lib="es2015.d.ts" />.

  • Q: What about /// <reference no-default-lib="true"/>?

    • This PR ignores any /// <reference no-default-lib="true"/> comments.
  • Could also do /// <reference lib="..." /> in lib.d.ts as well.

    • Let's do that.
  • What about Daniel's lib versioning idea of publishing to @types?

    • Example: DOM APIs require new logic - suddenly breaks certain builds.
    • People would be able to go to a specific version of a lib if they got broken, or just lock down all their dependencies.
    • Also might allow us to bring node.d.ts in.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jun 9, 2017
@mhegazy mhegazy closed this as completed Jun 12, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants