Skip to content

Conversation

noti0na1
Copy link
Member

No description provided.

@noti0na1 noti0na1 requested a review from olhotak August 25, 2025 13:13
@bishabosha
Copy link
Member

bishabosha commented Aug 25, 2025

didnt this already ship in Scala 3.5?

@noti0na1
Copy link
Member Author

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

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`):
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants