-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-initialisation of string literal types in some circumstances #1486
Comments
This is kind of scary. What would the behavior for this code be, for example? interface A { P: "P"; }
interface B { P: "Q"; }
interface C { X: "Y"; }
var x: A|B = {};
var y: A|C = {}; |
Behaviour will be exactly as in the prototype of @Nevor. i.e. this suggestion makes no difference to those examples. As The point of this suggestion is purely to avoid redundancy when the user has already definitely chosen A, B or C, because they've restricting the type that the object literal is being assigned to, and therefore it would be pure ceremony for them to have to specify any implied literal constant(s). In your examples, the context doesn't provide any such certainty, the compiler can't do anything to fill in any blanks, and so would not. |
This looks like a lot of magic. it is not clear when this would happen and when it would not. how can users opt-out of this auto-initialization? what if the object literal has some property declarations, does the auto-initialization still occur? what about optional properties? what about properties that does not have default values... |
I think an auto-completion list will be better here. |
+1 for @saschanaz proposal. |
#606 discusses auto-completion of string literals so maybe we can talk more there. |
Regarding issue #1003. Given:
All of the following are valid:
But (consistent with TS 1.3) this is not, because it doesn't explicitly initialise
P
:I suggest the compiler behave as if
P
had been initialised, as forv4
. This is the overwhelmingly likely option and avoids the redundancy of both stating the typeA
and repeating the definition ofP
.For classes:
I suggest for C1 and C2 the compiler behave as for C3, for a similar reason: that's almost certain to be what I'd have to write out by hand.
The text was updated successfully, but these errors were encountered: