Closed
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
readonly
modifier for tuple properties - And
Readonly
doesn'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.isArray
work correctly forReadonlyArray
s?- Maybe.
- There's on little nit to it
- The fact that
Array
is not assignable toReadonlyArray
, but aT
is 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
Readonly
to 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 withreadonly
properties?"
- "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
readonly
keyword that you contextual type, or usingas readonly
oras 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 becausereadonly
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 T
≤not U
ifU
≤T
S
≤not T
ifS & 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
number
from 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 & string
NonNullable<T>
=T & not null & not undefined
Truthy<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