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

Proposal: Consider introducing a shorthand syntax for nullable types #18430

Closed
MartinHaeusler opened this issue Sep 13, 2017 · 4 comments
Closed
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@MartinHaeusler
Copy link

Static analysis on "nullable" variables is a good thing. However, using this feature also requires to explicitly create union types with null for every variable and member that can in fact be null. So, for example to create a nullable (and undefineable) number member...

interface MyInterface {
  x: number | null | undefined
}

It is currently possible to use a shortcut for undefined:

interface MyInterface {
   x?: number | null
}

Note that the two interface definitions above are equivalent, but | null is always required.

However, for my taste, this is all way too verbose for something as common as a nullable type. I would like to propose the following:

interface MyInterface {
   x: number?
}

... where number? is the shorthand for number | null | undefined. This little tweak would save a lot of typing and improve general acceptance of strict null checking. This isn't a new idea. Languages like Ceylon use the same method and syntax.

@aluanhaddad
Copy link
Contributor

See #7426 where a long and contentious debate has taken place.

@MartinHaeusler
Copy link
Author

MartinHaeusler commented Sep 13, 2017

Thanks for the pointer, but the discussion in this ticket seems a bit... inconclusive to me? The other ticket is closed, but I can't see clearly what the upshot of the discussion was (without having read the entire thing).

@ahejlsberg
Copy link
Member

Conclusion is here: #7426 (comment). Basically, there is no consensus on what T? should mean and therefore we don't have a shorthand notation.

@ahejlsberg ahejlsberg added the Working as Intended The behavior described is the intended behavior; this is not a bug label Sep 13, 2017
@RyanCavanaugh
Copy link
Member

See also #7488

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants