@bishabosha How do you mean “repurpose
asMatchable "? That sounds really interesting!
@bishabosha How do you mean “repurpose
so currently we have
package compiletime extension [T](x: T) transparent inline def asMatchable: x.type & Matchable = x.asInstanceOf[x.type & Matchable]
Casts a value to be
Matchable. This is needed if the value’s type is an unconstrained type parameter and the value is the scrutinee of a match expression. This is normally disallowed since it violates parametricity and allows to uncover implementation details that were intended to be hidden. The
asMatchableescape hatch should be used sparingly. It’s usually better to constrain the scrutinee type to be
Matchablein the first place.
so could we change the body to add the new
: @checkedCast ascription?
This is intriguing! Simple and beautiful! I cannot currently find any downsides to this, other than that we perhaps overload the usage of
asMatchable, but it is for a similar purpose, so why not!? The advantage is that the change is minimal and it is already there. (The doc comment needs to be updated in a good way to explain its dual usage, perhaps with a nice set of examples in the doc.)
What do you think @odersky ?
For my taste it would overload
asMatchable too much.
asMatchable means turn a type (like
Any or an opaque type alias) that is usually not matchable into something that is matchable, which risks revealing the implementation of the type in ways that break encapsulation. The danger of
asMatchable is that you can then do something you are not supposed to by the type contract. E.g. mutating
The meaning of
checkedCast is quite different. I think I also like
runtimeCheck as a name.
OK yeah, conflating two usages might not be that good after all. An indication of this not being an optimal solution is that the docs would be long and elaborate for a “repurposed
It now seems like a ripe time for a conclusion on this:
- Change the name of the annotation
@checkedCastor similar by means of deprecation
def runtimeCheckto Predef as an extension that uses the new annotation
Is this a big enough change to require a SIP? I guess we are conservative with regards to Predef changes - but I’m unsure about the formal process here… @anatoliykmetyuk )
my reasoning is that
checkedCast is doing the same, e.g. revealing a
List unsafely as a
::, maybe there can be similar abuses of encapsulation
Conversion doing exactly this, it’s been suggested at least once. Treating things as type is unreasonably useful
For what it’s worth: I’m in favor of
runtimeCheck as a name, I think it’s the best proposed so far
I am in favour of
runtimeChecked as it aligns better with
if you can take as long as you want, it is
We discussed with the Scala Center and LAMP team about whether Predef changes warrant a SIP. It’s a tricky question since on one hand we don’t want the standard library to receive special treatment, on the other hand, it already does
So I’d say to be on the safer side it’d be good to pipe the change through the formal SIP process as it does affect the users almost on the level of a change to the language itself.
OK. I won’t have the time to draw up a SIP on this by myself. Is anybody up to co-proposing it?
Just to be clear what we want:
- An extension method in Predef named
- Expanding into a new annotation annotation.RuntimeCheck
extension [T](x: T) transparent inline def runtimeCheck: x.type = x: @annotation.RuntimeCheck
I can do it
Voice from the peanut gallery:
I would prefer the annotation to be called
compiletime.assumeType. (Or something along that.)
I think this would give a good experience understanding this feature in case you find some code using it. Code-surfing from
runtimeCheck would take you to
extension [T](x: T) transparent inline def runtimeCheck: x.type = x: @compiletime.assumeType
This clearly explains the feature in one line, imho.
It’s better than saying two times “runtime check” without noting this involves lessening compile-time safety.
Oh! But what about regular
unsafe stuff on Scala Native (which is still “regular Scala”)? Could I call
runtimeCheck on some
unsafe construct? What would happen? Or would this somehow magically force runtime checks on Scala Native
unsafe constructs? (I guess this can’t work like that. But maybe this feature could be disabled for Scala Native
unsafe things. If not, it needs some other name, I guess). Or is Scala Native
unsafe stuff actually irrelevant here?
This sounds so [[censored]] exciting, I can’t hold my horses!!!
Pluggable, user definable type systems look like the future of programming to me. Very cool Scala could be once more on the forefront of such revolutionary movement!
Great to see you are excited! The project is worked on by @mbovel and some master students at EPFL. For now, it’s strictly research.
I don’t know where the project is at right now, but I worked on syntax and runtime checks for it as my Master thesis. You can find my presentation slides here: go.epfl.ch/QT-slides.
But this was very early work, so don’t take anything from there as an indication of what is-to-be.
Notably I was in favor of heavily incorporating qualified types into the language (which you can see reflected in my work), but this has many downsides (and upsides of course), and so might not be chosen as the direction for the project.
(Or might have already been discarded)
Regardless, let’s put the subject aside for now, and I’m sure LARA and LAMP (the two labs working on it) will let us know here when it is more concrete !
I didn’t forget if anyone is thinking