Design Meeting Notes, 5/3/2024

[DanielRosenwasser]

Returnless functions in isolatedDeclarations

https://github.com/microsoft/TypeScript/issues/58330

/** Inferred as void */
export function f() {
    g();
}

/** Inferred as never */
export const x = () => {
    g();
};

function g(): never {
    throw null;
}

• Which is preferable: making declarations and expressions have consistent behavior under --isolatedDeclarations, or support better ergonomiccs on isolatedDeclarations?
• Under isolated declarations, we may "unnecessarily" require you to annotate f as void.
  • This is only because of consistency with function expressions, where they may be inferred as never.
• The rules for when we infer never in a function expression are well-established.
  • Will we ever want to change it?
    • Uhhhh...
• Why did we do that?
  • We didn't want to break code that throws and then gets overridden, or is then
• If we did this, we'd likely be locking down our behavior.
  • Every other tool would have to change behavior if we change our minds.
• Maybe - that said, we'd never change these to be never, we'd change them to only possibly be undefined.
• We really like the idea of keeping design room open to ourselves. So we'll keep the consistency of saying "you must write void here".

Expose a subset of current compiler options to type system

https://github.com/microsoft/TypeScript/pull/58396

• 50196 was proposed.

  • Related: @phryneas/ts-version, a package that leverages typesVersions to tell you what version of TS you're on.
  • People trying to do things like this to figure out certain compiler options.
• We want to discuss how this relates to using a flag for TReturn/TNext in Iterable/IterableIterator, as well as broader use cases and determine if this is a direction we want to take, which options to expose, and what to name the type.
• This work could allow lib.d.ts (or others) to decide on the type of TReturn/TNext, or types of other things, based on --strictNullChecks, --noImplicitAny, etc.
• Lots of examples using TypeScriptSettings extends { strictFunctionTypes: T } ? T : never or similar. Why not just TypeScriptSettings["strictFunctionTypes"]?
  • Code where TypeScriptSettings is forward-declared, maybe doesn't have a given option.
    • But now you can accidentally use a flag that doesn't exist (misspelled flag names).
• People've asked for this for a long time - but conditional compilation makes things extremely hard to diagnose.
• Ability for misuse is high with this. Shipping it is a green light to tell people to use it.
  • Misspelling options was one example.
  • Exposing lib - is lib really the right way to go about this?
• typesVersions
• Very broad, but not powerful enough to express places where conditional compilation doesn't solve big problems.
  • e.g. global variable that depends on context.
• Fair points - main interest was specific type-checking options.
• Is it good if someone turns on noImplicitAny and that affects some code in a clever way?
• Regarding "shipping it is a green light to tell people to use it": could name it __TypeScriptSettingsDoNotUse?
  • TSCONFIG_YOU_WILL_BE_FIRED
• How does this atually solve things for TReturn/TNext?

  • type BuiltinIteratorReturn<T> = TypeScriptSettings["noUncheckedIndexedAccess"] extends true ? T | undefined : T;

• Feels like we are not getting enough of a positive read from this approach. We get the use-cases, but the potential downsides are too big.

Have a consistent position for where some errors are reported

57842

• Have open question of what position to use and in which files.
• We've had issues about diagnostic positions which change depending on which syntax nodes get checked first.
  • For example, we have Cannot find module '@emotion/react/jsx-runtime' or its corresponding type declarations. that will be reported on the first place we check.
  • But that could be issued in a file that's not even open!
  • Could say this is a global error with no span, we could say that it's done once per file.
  • Technically this specific error shouldn't be a global error! It's file-specific.
• Another with This syntax requires an imported helper but module 'tslib' cannot be found..
  • This is a global error, but it's reported in the first file that gets checked.
  • Arguably, this is also per-file.
• It would be good if the CLI deduplicated many of these. Let's clean this all up first.

[fatcerberus]

FWIW, the never return type inference for arrow functions doesn't seem super useful - it can't be used for control flow anyway as that requires an explicit annotation.