Skip to content

Design Meeting Notes, 12/13/2023 #56798

Closed
@DanielRosenwasser

Description

@DanielRosenwasser

Preventing inference to a type parameter (NoInfer)

#14829

#52968

  • Old PR adds a new type kind (29th TypeFlag!)
  • There is a tail of places where NoInfer needs to be handled/sanitized.
    • Getting apparent types, etc.
  • But the work required to do this is identical to what we do with substitution types.
    • So we have a prototype of NoInfer that is built atop substitution types.
  • Some get unhappy in some cases when two candidates fail - but just giving people the ability to control this can alleviate the issue.
  • You can now declare a type parameter that never is inferred to. You'll need to provide a type argument. Is that understood and considered okay?
    • Yes.
    • Technically it's not the case that you'll need a type argument, you'll just end up with the default type argument.
  • Are there places where you as a user would want to disable return type inference?
    • const foo: annotation = getSomeFoo()
    • Hard to remember where these came up.
    • Mostly fixed const { x, y, z } = genericFunc(), but should review those.
  • Going to experiment here.
  • [[Later addition: Add NoInfer<T> intrinsic represented as special substitution type #56794 ]]

Making Arrays into Tuples When Assigning to Homomorphic Mapped Types

#56555

  • We know homomorphic mapped types preserve tuple inputs.
  • Preserving tuple-shapeness means you can infer better to the mapped type.
  • We think that sounds right!

Comparing Against Apparent Keys of Target Type Source Has Deferred Index Type

#56742

  • Scenario is keyof SourceMappedType -> keyof TargetMappedType
  • Generally speaking, this reflects the same logic we take around how we construct types, just the reverse as we pick things apart.

Modules!

  • Been working on finer-grained module options.
  • A few scenarios we have been trying to fix:
    • Accurately modeling bundler behavior (some which work closer to Node, some which always work with ESM)
    • Shipping CJS/ESM
  • CJS/ESM
    • Could try to do some shenanigans
    • tshy and bundlers like tsup help with these scenarios.
    • Does it make sense to try to "address" CJS/ESM?
      • Maybe as far as type-checking goes?
      • But there's some subtlety because there is pre-bundler and post-bundler.
      • The inputs may be assumed to all "just work" within bundler, but the outputs will be running in nodenext.
  • Declaration emit
    • The files should really reflect what the bundler does.

Activity

fatcerberus

fatcerberus commented on Dec 15, 2023

@fatcerberus

Heads up: The "later addition" issue link is broken.

DanielRosenwasser

DanielRosenwasser commented on Dec 15, 2023

@DanielRosenwasser
MemberAuthor

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @DanielRosenwasser@fatcerberus@RyanCavanaugh

        Issue actions

          Design Meeting Notes, 12/13/2023 · Issue #56798 · microsoft/TypeScript