-
Notifications
You must be signed in to change notification settings - Fork 28
SIP-XX - Flexible Types in TASTy format #115
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
base: main
Are you sure you want to change the base?
Conversation
didnt this already ship in Scala 3.5? |
The implementation has been shipped. The core team is asking for a SIP to finalize the tag in TASTy. See the discussion at: scala/scala3#23682 |
|
||
### High-level overview | ||
|
||
We introduce Flexible Types as a compiler-internal representation that allows a type to be treated as both nullable and non-nullable depending on the context. A Flexible Type `T?` (notation borrowed from Kotlin's platform types) has bounds `T | Null <: T? <: T`, meaning: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We introduce Flexible Types as a compiler-internal representation that allows a type to be treated as both nullable and non-nullable depending on the context. A Flexible Type `T?` (notation borrowed from Kotlin's platform types) has bounds `T | Null <: T? <: T`, meaning: | |
We introduce Flexible Types as an Internal Type (see 3.1 of the spec) that allows a type to be treated as both nullable and non-nullable depending on the context. A Flexible Type `T?` (notation borrowed from Kotlin's platform types) has bounds `T | Null <: T? <: T`, meaning: |
This is not at all compiler-internal. If it were, it wouldn't need a SIP. It is an Internal Type, which has meaning in the spec, and has specified subtyping rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a spec point of view, it makes no sense for a type to have bounds. Only type definitions can have bounds. Here, what we need is to add adequate typing rules covering cases of flexible types.
|
||
#### TASTy Format Extension | ||
|
||
We extend the TASTy format with a new type tag (`193`): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than define TASTy format things (which are not covered by the spec per se), what we need here is new subsection 3.1.x in the spec to define the abstract syntax of a flexible type.
No description provided.