| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
TypeScript Bot (@typescript-bot) pack this |
Sorry, something went wrong.
|
Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the tarball bundle task on this PR at 6f09705. You can monitor the build here. |
Sorry, something went wrong.
|
Hey Ryan Cavanaugh (@RyanCavanaugh), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so: {
"devDependencies": {
"typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/93799/artifacts?artifactName=tgz&fileId=3EC3DF89823D37BAFB0102D05E0C5878E1CC64D470DA739FA701667C9C8CEEC602&fileName=/typescript-4.2.0-insiders.20210120.tgz"
}
}
and then running npm install. There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.2.0-pr-42425-2".; |
Sorry, something went wrong.
|
TypeScript Bot (@typescript-bot) pack this |
Sorry, something went wrong.
|
Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the tarball bundle task on this PR at d2affa2. You can monitor the build here. |
Sorry, something went wrong.
|
Hey Ryan Cavanaugh (@RyanCavanaugh), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so: {
"devDependencies": {
"typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/94491/artifacts?artifactName=tgz&fileId=5D2DE7C1D3D1A47BE543A3A8978BBC0D64E3E7103505294FB8EDC8B577A31AA302&fileName=/typescript-4.2.0-insiders.20210129.tgz"
}
}
and then running npm install. There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.2.0-pr-42425-5".; |
Sorry, something went wrong.
|
What milestone will this go into? |
Sorry, something went wrong.
…ariant accessor types in TypeScript This make accessors have the correct types to represent all possible values that they can be set to, but the getters are funky because to use them it requires type casting. As a temporary workaround, `get*()` methods have been added (f.e. `element.getPosition()` returns the same as `element.position` but with the value casted to the underlying object type. This does not impact JavaScript users. They can continue to do things like `element.position.x = 123`. But TypeScript users can't do that. They would have to write `;(element.position as XYZNumberValues).x = 123` which is cumbersome, but the temporary getter methods allow TypeScript users to write `element.getPosition().x = 123` instead. TypeScript users can still set values as usual: `this.position = [1, 2, 3]` just like JavaScript users. The upcoming changes in microsoft/TypeScript#42425 will allow us to update the getter types so TypeScript users can write `element.position.x = 123`.
|
TypeScript Bot (@typescript-bot) pack this |
Sorry, something went wrong.
|
Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the tarball bundle task on this PR at b7f93bb. You can monitor the build here. |
Sorry, something went wrong.
|
Hey Ryan Cavanaugh (@RyanCavanaugh), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so: {
"devDependencies": {
"typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/99188/artifacts?artifactName=tgz&fileId=8A4F5CF4310E72AE3F3599DB677A807009BC386229856DAD4B06C74D77071B7702&fileName=/typescript-4.3.0-insiders.20210325.tgz"
}
}
and then running npm install. There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.3.0-pr-42425-10".; |
Sorry, something went wrong.
# Conflicts: # src/compiler/checker.ts # src/compiler/diagnosticMessages.json # tests/baselines/reference/privateNamesAndGenericClasses-2.errors.txt
This will depend on microsoft/TypeScript#42425 landing in stable TypeScript so we can update the types to reflect it.
|
What's the syntax (if supported) for generic types? type MarkAsString<T extends Record<string, any>> = {
[K in keyof T]: T extends number ? T[K] /* How to set add a string|number set here? */ : T[K]
}
declare const a: MarkAsString<{ a: boolean, b: number, c: string }>
a.b = '42'; // I want to have this avalible
a.c = '112'
// @ts-expect-error
a.a = '2'Actual use caseIn Vue3 there's Ref<T> (simplified as { value: T}) and Reactive<UnwrappedRef<T>> (unwraps {value: T} to T, recursive) const r = ref({ a: 1} )
r.value.a = 1
const a = reactive(r)
a.a // 1On a reactive/ref object the set in typescript must be UnwrappedRef<T> which is not true, because when you assign to a reactive it will unwrap the value: const r = ref({a:1});
const a = ref({
r
}) // results in `{ r: { a: 1 } }`
a.r = r; // typescript error because `r` is `Ref<T>` instead of `UnwrappedRef<T>`, but it works at runtime. |
Sorry, something went wrong.
|
I think what you're actually looking for is how to use the new feature with index signatures. My first guess would have been something like interface ConvertingRecord {
get [k: string](): string;
set [k: string](val: string | number);
}
but that doesn't work on the latest Playground for this build. Maybe it's not currently possible? |
Sorry, something went wrong.
|
Yeah, that's a totally separate and additional feature. |
Sorry, something went wrong.
Cool, should I open an issue? |
Sorry, something went wrong.
|
Sure |
Sorry, something went wrong.
|
This is very cool, is there any information on which version will have this change? |
Sorry, something went wrong.
|
Dmitry Shamshurin (@V1raNi) This has been shipped in 4.3 https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-3.html#separate-write-types-on-properties |
Sorry, something went wrong.
|
The different type for setter doesn't work for Union type as well. Is this expected? Example can be found here |
Sorry, something went wrong.
|
Wei (@ws93) I didn't see an issue for that yet so I went ahead and opened #45376 . |
Sorry, something went wrong.
Oh, thank you very much. It's just I was interested in different visibility and couldn't find it in the text, and the docs seem to be outdated a bit regarding this part. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Getter / Setter Variation
Implements #2845 and #2521
Overview
This implements two related features:
Differing Types
Property getters and setters may now differ in their types:
Restrictions
As a conservative implementation, a few restrictions are in place.
First, the type of the getter must be assignable to the type of the setter. In other words, the assignment
must be legal assuming obj.x is writable at all.
This restriction closes off a certain set of use cases for properties that start out "uninitialized" (usually null/undefined) but then only want "initalizing" assignments to occur. We'll continue to examine these to see if those use cases are prevelant enough to warrant opening this up more.
These prevent novel unsoundness from occurring and makes this feature unimpactful from a type relational perspective, which limits its risk.
Differing Visibility
In classes, set accessors may now be less visible than their corresponding get accessor. It looks like this:
Type Relationship Effects
TL;DR: there are none
TypeScript is already covariant when relating properties of types. The unsoundness of this is straightforward to demonstrate during aliased writes:
TypeScript also already ignores the readonly modifier when relating types, so the protected or private state of a setter does follows the same pattern.
Caveats
TL;DR: The type system remains entirely covariant in other operations! This has some effects that may not be immediately apparent.
Types with variant getters/setters are effectively reduced to their get side when put through mapped types:
This is fairly straightforward to reason about -- a mapped type usually represents a "copy with transform" operation, e.g.
(psuedocode: some type operation f applied to an object type obj) result = { } for k in keyof obj result[k] = f(obj[k]); return resultIn other words, for an arbitrary mapped type, we have no idea how its actual value is produced, and the only sound assumption is that this type doesn't copy over any coercing semantics from its setters.
The same applies to lookup types -- the type T[K] still means *the read type of K on T. A free setter function can't be used to indirectly access the coercing side of the setter: