Description
Narrowed read-only properties in functions
- We usually disregard narrowing for values captured in functions.
- Unless they're
const
.
- Unless they're
- We don't narrow in functions for properties.
- Someone
- However, as mentioned
readonly
doesn't disallow aliasing of a mutable value.const
has different semantics
- You can think of
readonly
as a read-only view into some value.-
Aliasing means you can't guarantee other mutations
let y: { a: string | undefined } = { a: 's' } const x: { readonly a: string | undefined } = y; if (typeof x.a !== 'undefined') { y.a = undefined; () => x.a.length; }
-
- If we look at some examples in Trade-offs in Control Flow Analysis #9998, it seems somewhat arguable.
- Given the fact the you only have write-ability restrictions on your reference of a property,
- Conclusion: let's close it
Changing implicit constraints from {}
to unknown
-
We have assumptions that all type parameters (e.g.
T
) are assignable to{}
, even though an instantiation may benull
orundefined
. -
Really, we should say that the default constraint for all generics are
unknown
. -
This would definitely break stuff.
- The question is not whether this will break stuff, but
- how much will it break?
- are the breaks good?
- The question is not whether this will break stuff, but
-
We didn't want to "rock the boat" when we shipped
strictNullChecks
by changing the constraints.- Didn't have
unknown
at the time. - The type would be unreadable as
{} | null | undefined
.
- Didn't have
-
Would want to do this in
strictNullChecks
? -
What about outside of
strictNullChecks
?- Maybe we should make
unknown
assignable to{}
.- Sounds like you're pushing the problem down the road if you ever switch into
strictNullChecks
?- But that's future-you's problem.
- Sounds like you're pushing the problem down the road if you ever switch into
- Maybe we should make
-
Should consider
unknown
the "toppest" type. -
Idea: we really only want new errors in the declaration, not call sites:
function foo<T extends unknown>(x: T, y: T) { // declaration let z: {} = x; } // call foo(null, 100);
-
Should we also be looking at all the places in the compiler that use
{}
?- Probably.
-
Conclusion: let's try changing the default constraint for type parameters to
unknown
(and also change them not to be assignable to{}
(but only tounknown
)).- see what breaks
Support for "typesVersions" redirects
- We currently can't make changes to Node's
.d.ts
because of backwards-compatibility. - Ideally, we could publish one package that had all the versions in different
.d.ts
files. - Other situation: someone wants to use the latest features of TypeScript, but those features end up in their
.d.ts
files. - Proposal:
typesVersions
- A new field in
package.json
that maps versions ranges to path-mappings.
- A new field in
- We also discussed encoding this information into file names when resolving.
- Coming up with a resolution strategy seems a litle bit fuzzy.
- Do you need both a
types
and atypesVersions
field inpackage.json
?- Yes! At least if you care about older versions of TypeScript (e.g. versions prior to whenever
typesVersion
was supported). In those cases,types
should point to a file that supports the oldest version of TypeScript.
- Yes! At least if you care about older versions of TypeScript (e.g. versions prior to whenever
- Does this really solve the "new types leak into my
.d.ts
files" issue?- Depends on what you want to do.
- If your API doesn't change that much, ship stale
.d.ts
and maybe that's okay. - Otherwise you can write a tool that replaces types.
- If your API doesn't change that much, ship stale
- Depends on what you want to do.
- Is this compatible with the tagging strategy on DefinitelyTyped?
- Currently the types-publisher tool looks for
// TypeScript Version: X.Y
on.d.ts
file headers in DefinitelyTyped and tags them astsX.Y
. - We may be able to stop publishing tags.
- ...but it might be safer to wait a version.
- Currently the types-publisher tool looks for
- How does this interact with the layouts for different package versions in DefinitelyTyped?
- @Andy-MS is coming up with a proposal.
- Concerns about complexity, but this is meant for power-user package authors.