Design Meeting Notes, 10/4/2023

[DanielRosenwasser]

Unique Symbols, Widening, and Declaration Emit

#55901
#55943

export const l = "A";
export const l1 = l as typeof l;
export const l2 = l;
export let l3 = l as typeof l;
export let a4 = l;

export const s = Symbol();
export const s1 = s as typeof s;
export const s2 = s;
export let s3 = s as typeof s;
export let s4 = s;

• Two kinds of symbols, widened and non-widened.
• For declaration emit, s1 should say typeof s.
  • One recollection of this behavior was that unique symbol widening was very bespoke because fleshing out a broader ruleset was difficult at the time.
    • Questionable recollection. unique symbol incorrectly widens to symbol when assigning to a const or readonly property #23263 (comment)
• Could imagine an alternative world where unique symbol is the default - we don't widen those away. You say : symbol if you want to handle arbitrary symbols.
  • What about widening return values from functions?
• We don't widen fresh literals all the time - conditional types don't work the same.
• Other view: unique symbols widen just like all other literal types.
• Let's try https://github.com/microsoft/TypeScript/pulls/55943 in 5.4 with literal widening unification.

Uninitialized Variable Checks

#23305

• We don't do control flow analysis across functions, so we can't catch "you never initialized this" checks across function boundaries.
• error on variables that are used but never initialized #55887 is a PR to say "if a variable was never ever set but it's used somewhere, it's an error"
• There's some cases where "I'm temporarily erasing some code and I don't want an error"
  • Well add a ! or say the variable is possibly undefined.
• We need to have tests for a ! as both a non-null assertion and an initialized variable assertion.
• Would be better to do this on the use-site.
• Also a better error message would be "is never initialized".
• Should just let x: string with no usages at all be an error?
  • Hate this because "I'm not done typing", but can be caught by unused variable checks/linters.

Stage Advancement Planning

• At TC39, there was a proposal that ECMA262/TC39 should change the staging process to add a new stage between Stages 2 and 3.
• Results at plenary:
  • Consensus: there should be a new stage
  • No consensus: name of the stage (2 ¾, 3.a/3.b, add a new stage and shift 3 and 4 over to 4 and 5...)
    • Mostly devolved into jokes.
    • We would just prefer to insert a new thing and shift 3/4 over to 4/5.
• Issue is that proposals need to have tests before implementers start implementing.
  • Polyfills, possibly eager compilers will implement at the new pre-today's-stage-3 stage
  • Everything else will implement after tests are written.
• We will probably implement/ship post-tests, not pre-tests.
  • We rarely do the "ship it behind a flag".
  • We can implement early for feedback as implementers/users, but we won't ship early.

[fatcerberus]

Just a heads-up: The links for the PR (#55943) are broken at the time this was posted.

[fatcerberus]

I'm kind of curious how the new ES stage would work out in practice. The current stages are very well-delineated with concrete meanings (1 - investigation, 2 - active development, 3 - implement and get feedback, 4 - final spec) which is quite nice; adding any more stages feels like it'd just shift things into more abstract territory and blur the nicely drawn lines over time.

[DanielRosenwasser]

(fixed, and I resent that pulls and pull are two distinct URLs)

[DanielRosenwasser]

If I understand correctly, it would basically be

1. investigation
2. active development
3. develop tests
4. implement and get feedback
5. final spec

[fatcerberus]

I resent that pulls and pull are two distinct URLs

That’s why sometimes I’ll note the issue number and then just delete the URL and type #55943 to let GH turn it into a link, which has the bonus that you don’t have to remember whether it’s an issue or PR.

P.S.: You didn’t fix the second one 😉