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/18/2020 #39154

Closed
DanielRosenwasser opened this issue Jun 18, 2020 · 1 comment
Closed

Design Meeting Notes, 6/18/2020 #39154

DanielRosenwasser opened this issue Jun 18, 2020 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Variadic Tuples

#39094

Added the ability to add a "cut point" to inference to accurately describe curry.

function curry<T extends unknown[], U extends unknown[], R>(
    f: (...args: [...T, ...U]) => R,
    ...a: T
)

This is complicated! Why?

  • You want to get the count from ...a to know how much to cut off from [...T, ...U]`
  • You want ...a to be contextually typed by whatever it could be inferred from ...args
  • So we now try to build up a concept of "implied arity" from these positions during the inference process.

There are some limitations around inference in certain more complex cases.

function independent<T extends unknown[], R>(
    ...args: [...T, (...a: T) => R]
): [T, R];

Works well for

[fixed-part, ...rest-part]

but not

[starting-fixed-part, ...rest-part, ending-fixed-part]
[...rest-part, fixed-part]

but...we think we could! Then we could model

declare const foo: string[];

independent(...foo, (...args) => hello)
  • What about pipe?
    • Common, but is very complicated to type without pyramids of overloads.
    • There's also compose which is more right to left, which we couldn't do.
    • Wasn't within scope for this PR.
    • Maybe potential in the future, but also, maybe |> is the better solution.
  • We had some questions about applying mapped type transformations across different places.
    • Turns out that we don't encode the right information to say that when constrained to a union of array/tuple types, a homomorphic mapped type will also be array/tuple-like.
    • Instead, we just assume that the thing is more plain object-like than array-like.
      • Basically the same as behavior of mapped types on arrays before they were special-cased in around TS2.9ish.

Spreading anyTypeExpr && otherExpr into Objects

#39113

function fn(x: unknown) {
    const res = {
        // uh oh!
        // 'prop' is specified more than once, so this usage will be overwritten.
        prop: 100,
        // This spread always overwrites this property.
        ...(x && { prop: 200 }),
    };
}

Strange:

let x: string = (false as unknown) && "hello"; // okay
let y: string = (0 as number) && "hello"; // error

Conclusion: Try changing this behavior and see what breaks, but it sounds very breaky.

Switch to ES Maps and Sets

#33771

  • Internally we have a Map type, have logic that uses the native ES Map type if available.
  • But the problem is, because our polyfill only worked on strings keys, our Map was limited like that all-around.
  • Will switch to having K, V.
  • WeakMap?
    • Not if we can help it, avoid using in compiler.
  • What about breaking change?
    • Very esoteric use-sites in our API.
  • Conclusion: Try the change in beta, work with build tool authors to see impact.

Out of time

Base tsconfigs

tsconfig/bases#15

Abstract Constructor Types

#36392

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jun 18, 2020
@awerlogus
Copy link

The best way to implement pipe without of overload pyramids is #38182. But as I see, nobody still really interested in this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

3 participants