Skip to content
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

Closed
danielearwicker opened this issue Dec 15, 2014 · 6 comments
Closed
Labels
Declined The issue was declined as something which matches the TypeScript vision Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript

Comments

@danielearwicker
Copy link

Regarding issue #1003. Given:

interface A { P: "P"; }

All of the following are valid:

var v1: A = { P: undefined };
var v2: A = { P: null };
var v3: A = { P: <any>5 };
var v4: A = { P: "P" };

But (consistent with TS 1.3) this is not, because it doesn't explicitly initialise P:

var v5: A = { };

I suggest the compiler behave as if P had been initialised, as for v4. This is the overwhelmingly likely option and avoids the redundancy of both stating the type A and repeating the definition of P.

For classes:

class C1 implements A { }
class C2 { P: "P" }
class C3 { P: "P" = "P" }

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.

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Revisit An issue worth coming back to labels Dec 17, 2014
@RyanCavanaugh
Copy link
Member

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 = {};

@danielearwicker
Copy link
Author

Behaviour will be exactly as in the prototype of @Nevor. i.e. this suggestion makes no difference to those examples. As {} does not satisfy any of those types, you'll get a compilation error.

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.

@mhegazy mhegazy added Declined The issue was declined as something which matches the TypeScript vision Out of Scope This idea sits outside of the TypeScript language design constraints and removed Revisit An issue worth coming back to labels Dec 10, 2015
@mhegazy
Copy link
Contributor

mhegazy commented Dec 10, 2015

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...

@mhegazy mhegazy closed this as completed Dec 10, 2015
@saschanaz
Copy link
Contributor

I think an auto-completion list will be better here.

@mhegazy
Copy link
Contributor

mhegazy commented Dec 10, 2015

+1 for @saschanaz proposal.

@saschanaz
Copy link
Contributor

#606 discusses auto-completion of string literals so maybe we can talk more there.

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Declined The issue was declined as something which matches the TypeScript vision Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants