-
Notifications
You must be signed in to change notification settings - Fork 214
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
Comments
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. |
No, this has no effect on any semantics. The name If there is no declaration in the source code, then each tool needs to inject the name into the 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 The current I'd have no issue with every tool doing things differently, except that if some tool wants a fake declaration in the |
In discussions with the analyzer team this morning, I think we were broadly coming around to not placing a synthetic class definition in |
Decision: Do not introduce a class declaration placeholder for Never. |
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 indart:core
.Should there be an explicit class declaration for
Never
insdk/lib/
(as there is forNull
,FutureOr
, andFunction
)? Or should it be implicitly declared bydart:core
, likedynamic
?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.
The text was updated successfully, but these errors were encountered: