-
Notifications
You must be signed in to change notification settings - Fork 13.1k
Closed
Labels
Design NotesNotes from our design meetingsNotes from our design meetings
Description
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
readonlymodifier for tuple properties - And
Readonlydoesn't specially treat arrays.
- We made changes so that homomorphic mapped types (like
- Proposing so that
- type system could make readonly slots in tuples
- transforms arrays to produce
ReadonlyArray.
- Could this help make
Array.isArraywork correctly forReadonlyArrays?- Maybe.
- There's on little nit to it
- The fact that
Arrayis not assignable toReadonlyArray, but aTis assignable to aReadonly<T>. - This is not the "end of the world".
- The fact that
- Concern: I don't like this because introducing what appears to be a minor inconsistency can have larger downstream effects.
- Homomorphic mapped types can't work on arrays while using constrained helper types #27375
- Rationale: we already generalized
Readonlyto make things readonly-ish consistently, we should generalize this.
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 withreadonlyproperties?"
- "You mean
- if contextually typed by something that's readonly, you should keep around readonliness
- Are we concerned with adding something to the expression space? Could we just have a
readonlykeyword that you contextual type, or usingas readonlyoras 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.
constmight be a better keyword becausereadonlyis 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
notis related contravariantly on its contained type.not T≤not UifU≤T
S≤not TifS & T=never.- Deferred (i.e. non-simplified) negated types never imply any relation with other types (i.e.
not T≰U).
-
Interesting topics
- Interplay with narrowing
- When you narrow out
numberfrom a generic typeT, should we intersect withnot number? (i.e. should you getT & 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 & stringNonNullable<T>=T & not null & not undefinedTruthy<T>=T & not (0 | "" | false | undefined | null)
- With
let x: { a: number } | string, narrowing withtypeof x === "string"you'd end up withstring & { a: number }. - What if you had a way to say that some of these object types never can overlap with another primitive.
- When you narrow out
- Interplay with mapped types?
- Interplay with narrowing
Out of time
Kingwl, xiaoxiangmoe, Bnaya, mpawelski, ulrichb and 1 more
Metadata
Metadata
Assignees
Labels
Design NotesNotes from our design meetingsNotes from our design meetings