Design Meeting Notes, 2/15/2019

[DanielRosenwasser]

Generic function composition

#29904

• The fact that we're not doing unification is nothing new.
• Inconsistency depending about strict mode is a very weird experience.
• But also seems weird that we're committed to backwards compatibility, but we think strict mode is the best way to operate.
• What if strict would be the default?
  • The problem is that strict always brings new checks in.
  • Even older commitments become questionable with strict mode
    • For example, strictness issues in Proposal: strict flag to prevent uninferrable generic types from being inferred as {} #27288 have been fixed with strictFunctionTypes.
• Many issues come from writing the overloads incorrectly.

  • Current implementation might be better written as

    let pipe: <A extends any[], B, C>(
        f: (...args: A) => B,
        g: (b: B) => C):
          (...args: A) => C

  • Works really well... sometimes.

    const fn = pipe(
        (a: number) => a * a,
        x => "hello " + x,
    );
    // (a: number) => string

  • Doesn't work when you have contextually sensitive parameters.

    const fn = pipe(
        (a, b) => true, // contextually sensitive
        x => "hello",
    );
    // (...args: any[]) => string
    // ...what?

  • Problem is we make no inferences for A, which jumps to the base constraint which is any[].

  • Shouldn't it have been constrained to unknown[]?

    • Maybe, but that doesn't fix the fact that it will still take an arbitrary arity (unknown[]) instead of maintaining the input arity [unknown, unknown].

  • So we're experimenting with a way to infer the shape for a spread-in type parameter. We're considering that a bug.

• To be explicit, we're not solving the "do arbitrarily complex function composition problem"

strict by default

• Returning to "strict by default" conversation
  • What if tsconfig-less projects were strict
  • Would break a lot of people using MSBuild, gulp, etc.
  • Could adopt a different versioning scheme and say in the next version we'll do strict.
  • "uhhhhhhhhhhhhhhhhhhhhhhhhhhh"
    • "how do you encode that sound in the design meeting notes?"
  • What's the behavior for checkJs?
    • Questionable if you want that to be strict
  • strict is turned on by default when you write tsc --init
    • Not everyone turns that on
    • "Well I always do"
      • and I'm just a humble member of the compiler team!
  • Could try to affect the the change by other venues
    • Do most boilerplates turn strict mode off?
• Would love to at least have strictNullChecks and strictFunctionTypes.
  • Maybe that's the idea? Individual flags instead of all of strict.
  • How do those compose?
    • You get never[] with strictNullChecks without noImplicitAny.
  • It took us months to adopt strictNullChecks.
• We should discuss what 4.0 means.
  • Would be reasonable to discuss a specific versioning strategy.
  • Not semver, but explicit expectations.
• One thing this means is that if we're a dial, we start in the middle rather than at the beginning.
  • This means that strictness is not purely additive.

[chriskrycho]

Not semver, but explicit expectations.

I know I and a bunch of other folks in the Ember community (and probably others!) would be very interested in what you all land on in that conversation. We're trying to sort out a what a SemVer-compatible strategy for official adoption of types looks like—because even if TS doesn't do SemVer, projects which use it do—and at a minimum clearer expectations about what kinds of things will and won't change in a point release would be hugely helpful for us as we work through that!

[MartinJohns]

• strict is turned on by default when you write tsc --init

A lot of people don't use that command to initialize the tsconfig.json file, but instead copy an old or a Googled version. Then they miss out the great features because they don't know about them. I frequently see new projects created with the strict flag missing due to nescience.