Skip to content

Design Meeting Notes, 8/4/2017 #17621

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions