I’m not trying to be mean, but this rhetoric has been repeated over and over in the previous discussions on Opaques. I then asked explicitly for examples of use cases which cannot already be achieved by wrapper classes (if we ignore performance), and there were two examples only – one is specific to Scala.js, and the other was rather unexplored (it raised a lot of questions and was not discussed at length).
I am not saying that these use cases are not valid and are not desired, nor do I object for a better performing implementation of wrapper classes (with caveats). I am saying that all of these do not satisfy the original motivation of the SIP, and those are all new and unrelated motivations, and that I still wish for a design that actually addresses the original motivation.
Yes, I want to expose all the methods from the underlying type. That’s how type aliases behave and why they are being used – to give a more meaningful name to a type and retain all of its functionality.
The SIP acknowledges this, by starting the motivation with:
Authors often introduce type aliases to differentiate many values that share a very common type.
And then immediately points out the problem with type aliases:
In some cases, these authors may believe that using type aliases […] means that if they later mix these values up, the compiler will catch their error.
What I want is to give meaningful names to generic types, while using them exactly the same way I’d use the underlying type (so far that’s what type aliases are for), only that the compiler will prevent me from accidentally mixing between them if they have the same underlying type, just like it would prevent me from mixing any two normal types.