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, 8/4/2017 #17621

Closed
DanielRosenwasser opened this issue Aug 4, 2017 · 1 comment
Closed

Design Meeting Notes, 8/4/2017 #17621

DanielRosenwasser opened this issue Aug 4, 2017 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Trailing commas in type argument/parameter lists

#16152

  • Argument lists and parameter lists both allow a trailing comma.
  • Probably more confusing than it helps.
  • Revisit if it ever comes up again.

Narrowing from index signature-originating properties

#17567

  • Control flow analysis currently only operates on the declared types of properties.
    • There is no declaration in this case.
  • Implementation takes place in getFlowTypeOfReference.
    • When we check if two references are the same, the symbols are the same.
  • We agree that this is the behavior that should happen.
  • Seems reasonable.
  • Would the dynamic names PR be helpful?
    • Symbol table would be created during checking.
    • Probably stay out of that territory.
  • Conclusion: mark as a hard-to-fix bug.

The promised type

#17077

image

  • With the strictVarianceChecks and other changes, we created a difficult situation for Promise/PromiseLike inference.

  • Today, if you have

    P.then(() => {
        if (doSomething()) {
            return 1
        }
        return Promise.resolve("abc");
    })

    Currently we end up with Promise<number | Promise<string>>.

  • There seemed to be some fixes our team was looking at with how we infer between union types.

  • This is difficult because now you have to get into some strange pattern-matching like behavior for unions.

  • What about a negation type?

    • Doesn't give you recursive drill-down.

Promised type operator

async function f<T>(x) {
    y = await x;
}
  • Adds an internal PromisedType<T>, which can be described by a new type operator called promised T.
  • "So this thing is hard-wired to Promise (or PromiseLike)?"
    • It's hard-wired to the functionality of await.
  • Are there type relations described for this type operator?
    • Yes, it's on the PR.
    • Sounds like there is some strange behavior between how these types relate to each other.
      • Current rules seem to imply S -> promised T iff S -> T.
        • But what about S = string and T = Promise<string>.
  • Difficulty here will be getting "higher order" type relationships correct.
  • Also, you have to avoid going off the rails if your thens aren't the right thens.
    • We were already making sure this worked for await anyway.

Name bike-shedding

  • No PromiseLike is ever assignable to the promise T.
    • More like the "eventual" of T.
    • await T?

Discussion among community

  • People want a more generalized construct.
    • This is fairly specialized.
    • Well, so is await and .then in the first place.
  • Array.prototype.concat exhibits same behavior
  • Lodash has some problems here too.
  • Array-flatten proposal will potentially complicate this.

Conclusion

  • Examine type relationships further.
  • Bikeshed on the name.
    • await, awaited?
      • These call attention to the fact that you're working with promises.
      • Point is to convey that it is strictly not creating a Promise/PromiseLike instance type.
    • fulfilled?
      • What a gross name.
      • Thesaurus suggests "consummated".

Non-null assertion type operator

#14366

  • Semantics of higher-order relations could be complex.
  • Would allowing a ! in typeof do what you want?
    • No.
  • Why don't we always carve off null | undefined from T[K]?
    • Seems a little strange.
      • Not the same as the expression-looking operator.
    • Cases where you're using any under the hood?
      • Seems like a lot of those would be handled by constraints of keyof.
    • When do you not want this behavior?
    • We'll have to think more about it.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Aug 4, 2017
@masaeedu
Copy link
Contributor

masaeedu commented Aug 4, 2017

Well, so is await and .then in the first place.

Sure, but the problem is that you'll either:

  1. Solve this problem over and over again (how do I refer to the return type of a function type? how do I refer to the value type of an array type? how do I refer to the Foo type of a Bar<Foo> type?), or
  2. Leave everyone who doesn't have a broadly applicable enough instance of the same problem in the lurch

We can't change how await or Promises work, because TypeScript has to describe JS. We can however change the kinds of concepts TypeScript uses to describe JS.

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