Skip to content

Design Meeting Notes, 1/11/2019 #29382

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

Readonly generalizations

  • We've had a smattering of issues that relate to readonly.
  • Also, we have a Readonly<T> today.
    • We made changes so that homomorphic mapped types (like Partial<T>) work on tuples
    • But there's no readonly modifier for tuple properties
    • And Readonly doesn't specially treat arrays.
  • Proposing so that
    • type system could make readonly slots in tuples
    • transforms arrays to produce ReadonlyArray.
  • Could this help make Array.isArray work correctly for ReadonlyArrays?
    • Maybe.
  • There's on little nit to it
    • The fact that Array is not assignable to ReadonlyArray, but a T is assignable to a Readonly<T>.
    • This is not the "end of the world".
  • Concern: I don't like this because introducing what appears to be a minor inconsistency can have larger downstream effects.

readonly expression operator

  • People keep running into issues where things widen because of mutability, and it bugs the hell out of them.
  • Ideas:
    • if contextually typed by something that's readonly, you should keep around readonliness
      • "You mean Readonly<T>, or just something with readonly properties?"
  • Are we concerned with adding something to the expression space? Could we just have a readonly keyword that you contextual type, or using as readonly or as const?
    • You don't always have a good contextual space.
    • Definitely a concern about introducing new syntax, but trailing syntax is hard to read.
    • <const>[1, 2, 3]
      • Gross.
    • const might be a better keyword because readonly is only a "view of the world" guarantee; you can't mutate, but someone else might.

Negated types

  • @bterlson: I'm so excited for this

  • @DanielRosenwasser: I feel a bit more negative about them.

  • @weswigham: many of my bugs correspond to people trying to express things with strange conditional types.

    • What people often want is to remove things from the domain.
  • @rbuckton: Can I make a not-not joke?

  • Type relationships

    • not is related contravariantly on its contained type.
      • not Tnot U if UT
    • Snot T if S & T = never.
    • Deferred (i.e. non-simplified) negated types never imply any relation with other types (i.e. not TU).
  • Interesting topics

    • Interplay with narrowing
      • When you narrow out number from a generic type T, should we intersect with not number? (i.e. should you get T & not number)?
      • Could we replace conditional types in Use lib conditional types for type facts if possible #22348 with negated types? They would compose.
        • Sort of, except for the fake mechanism for tagging types.
        • We've let people abuse intersection types with vacuous domains.
        • Okay, imagine this
          • Stringy<T> = T & string
          • NonNullable<T> = T & not null & not undefined
          • Truthy<T> = T & not (0 | "" | false | undefined | null)
        • With let x: { a: number } | string, narrowing with typeof x === "string" you'd end up with string & { a: number }.
        • What if you had a way to say that some of these object types never can overlap with another primitive.
    • Interplay with mapped types?

Out of time

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

    Issue actions