Skip to content

Should Never be explicitly declared in dart:core? #335

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

Closed
stereotype441 opened this issue Apr 29, 2019 · 4 comments
Closed

Should Never be explicitly declared in dart:core? #335

stereotype441 opened this issue Apr 29, 2019 · 4 comments
Labels
nnbd NNBD related issues

Comments

@stereotype441
Copy link
Member

It was decided in #262 that with NNBD, the bottom type should become first class (i.e. the user should be able to refer to it by name and use it as the type of variables and type parameters). In the draft specification, the type is called Never and is considered to be declared in dart:core.

Should there be an explicit class declaration for Never in sdk/lib/ (as there is for Null, FutureOr, and Function)? Or should it be implicitly declared by dart:core, like dynamic?

It would be good to have a decision about this up front, because it has a significant impact on the implementation, and we would rather not have to change horses in mid-stream. @bwilkerson and I believe that either choice has a similar implementation cost in the analyzer.

CC @kmillikin in case he wants to weigh in on the implementation cost in the front end.

@stereotype441 stereotype441 added the nnbd NNBD related issues label Apr 29, 2019
@munificent
Copy link
Member

Just for clarification, is the answer to this question something that can affect user-visible language semantics? I know it can affect things like "Go to Definition" on "Never", but I'm wondering if this is mostly a question of implementation strategy.

@lrhn
Copy link
Member

lrhn commented Apr 30, 2019

No, this has no effect on any semantics. The name Never is exported by dart:core and it denotes the bottom type. How we build that into our tools is entirely an implementation issue.

If there is no declaration in the source code, then each tool needs to inject the name into the dart:core export scope from scratch. This is how dynamic works.

If there is a declaration (is it a typedef or a class declaration?), then each tool needs to recognize this declartion and replace it with the correct type since Never is not a function or class type. This is what currently happens for FutureOr. We intended to remove the FutureOr class when it had been properly implemented by the language tools, but has never been urgent, and it does provide a way to add documentation that we can't for dynamic. It's just slightly confusing documentation because it looks like a class.

The current Function declaration is actually a class declaration, it just has so many restrictions and special cases that it might as well not be.
The current Null declaration is a class declaration. There is no need for that to change for NNBD, but if we ever get non-class value types, then Null would be a good candidate.

I'd have no issue with every tool doing things differently, except that if some tool wants a fake declaration in the dart:core source code, then all tools must be ready for it. This suggests that we should go with the dynamic behavior, because then each tool is free to start implementing it independently, without needing to coordinate around a common declaration.

@leafpetersen
Copy link
Member

In discussions with the analyzer team this morning, I think we were broadly coming around to not placing a synthetic class definition in dart:core, in part because it avoids issues around controlling the presence/absence of Never pre-NNBD release. It sounds like we're all comfortable with that path? If so I propose we resolve this as such.

@lrhn
Copy link
Member

lrhn commented May 1, 2019

Decision: Do not introduce a class declaration placeholder for Never.

@lrhn lrhn closed this as completed May 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
nnbd NNBD related issues
Projects
None yet
Development

No branches or pull requests

4 participants