Design Meeting Notes, 10/26/2018

[DanielRosenwasser]

Spread types ({ re, ...{re, ...{re, ...{re, ...visited}}}})

#10727

#21316 (comment)

• After we did conditional types, it became almost possible to correctly type rest/spread on conditional types.
  • You can convince yourself that Conditional types #21316 (comment) has a user-land spread that mostly "does the right thing"
    • Except that methods get turned into properties.
  • Today we have a heuristic that anything was declared as a method was probably a prototype method.
    • Except methods from object literals, because those don't actually have a method. Ugh, edge cases.
• We'd effectively need an ownkeyof or ownkeysof operator to distinguish between all properties and what we can sort of model as "own" properties.

function f1<T>(t: T, x: { a: string, b?: string }) {
    let z = {} as Spread<typeof t, typeof x>;
    z.a; // has type 'string'
    z.b; // wait, this is an error?
}

• Why is z.b an error?
  • Well you don't really know what b is going to be, so it seems strange that you'd know how to "do the right thing" with b.
  • Seems questionable that you can't access it; it could be Spread<typeof t, typeof x>["b"].
  • Weird.
  • It seems like users would expect this to just work.
    • But this is only overly-pedantic in the "higher order" (i.e. only comes up with generics).

In order to work on this, we found that there are some weird behaviors on accessing properties on mapped types:

function foo<T, K extends keyof T>(x: Pick<T, K>) {
    obj = { foo: 5 }; // error
    let x = obj.wat; // allowed: WAT?
}

• So is the idea really to introduce ownkeyof?
  • Seems wonky and isn't fully accurate.
• What about own T which would allow you to write keyof own T?
• Want to make sure we're actually solving the problem.
  • Action item: want use bigtsquery
    • Except that we can't search .tsx files (@urish pls)

Private fields in nightly releases

#28152

(Crux of this recorded by @weswigham)

We've been working with Bloomberg for a while on implementing this proposal, but if you've been following the proposal repo for tc39, there has been mixed feedback about its behavior and syntax. So despite it being stage 3, it seems wise to be conservative in adopting an implementation. We want to validate the proposal with users, and Bloomberg still wants to actually trial a real implementation. In order to get feedback, we'd need something actually published so people can experiment.

It's difficult to maintain things for a long time outside of master, and it'd be useful to run experiments on nightlies. In the past, our problem with experimental flags was that the community took a hard dependency on the feature. Rather than releasing it like experimentalDecorators, what if we introduce a new flag that only works on nightly builds? This emulates how Rust or Chrome run experiments in their nightlies that never hit a public release. We're concerned about this because there are still people with concerns around syntax despite it being stage 3. But stage 3 is where we've said TypeScript will consider implementations for proposals...

• If private fields are stage 3, it's stage 3. If the comittee changes it, we change it and it's out of our hands. We've said we'll support stage 3 features, so we should support them. Generally speaking I'd have no problem with implementing it, since if it breaks due to a spec change, it's not our fault.
• But I don't think this is an ordinary stage 3 feature.
• And it'll be a versioning hazard, since you'll be pinned to the TS version that we support.
• Fine, we can have the switch but nothing strange nightly-only stuff. Then at least it can be toggled off/changed for the final version.
  [*back and forth about stage 3 support and maintainability issues *]
• There are alternate designs to achieve private fields. So we should verify what it is that solves users' issues. Would it make sense to have a different published "nightly" with the experiments? A differently labeled npm tag?
• If we want to be impartial maybe we step back and just wait.
  • If we need an implementation, there's nothing wrong with a temporary fork on npm.

[Out of time]

[DanielRosenwasser]

In the end we followed up with our colleagues at Bloomberg and we realized that the idea of a separate fork published on npm could be seen negatively (even if it's not at all the intent). We'll continue working on https://github.com/Bloomberg/TypeScript and people can download and LKG'd version from there.

[urish]

@DanielRosenwasser just to confirm - so the .tsx file search isn't urgent for now?