Why burden the language with something that can be implemented as a library? That goes against Scala’s design principles.
Yes, so what? The user doesn’t have to deal with it, and even the code for the traits can be done mechanically as generated source – except for method redirection which needs to be curated. More on this later.
Strings are not primitive. They are just used like one.
I’ve already mentioned the design principle concern, so let’s talk about why it should not be provided as part of the standard library. First, I heard the standard library is intentionally being left alone for 3.0, so there’s that.
But more importantly, there hasn’t been enough exploration on the design of a library like this. Haskell’s newtype
isn’t a good match because Haskell doesn’t have inheritance, it doesn’t have to support the Java type hierarchy, and it isn’t object oriented.
The example implementation I gave is rather useless, because it has no methods other than extracting the value again, but simply inline/forwarding methods won’t work either for various reasons I remarked on before. Some existing methods would break the opacity and need to be excluded, some need modified type signatures, and some take primitive/string parameters that should not be changed to the opaque types, or have return values be likewise.
This is something that needs to be explored at length, tried out, and revised based on real world usage. For that matter, there might be a call for different designs to satisfy different needs, in which case it might be best not to have it in the standard library at all. But even if that’s the right place for it, it would probably be better to wait on valhalla and, at any rate, now is the wrong time.
It would be great to start a discussion or a project implementing such a library for Scala 3. That would be more productive, in my opinion.