Your "transparent inline class" is called `typeali...

# language-proposals

[diesieben07]

Your "transparent inline class" is called typealias 😉

[Marc Knaup]

No, that would lose the type safety.
val emaiAddress = username
inline class: error
typealias: no error

[diesieben07]

Yes, but what you propose also looses type-safety, you can use the inline class as if it was it's underlying type...

[diesieben07]

So I am not sure what the difference is.

[Marc Knaup]

The big difference is that I still can’t accidentally use type A where type B is expected.
I can still use for example all String mutations on A and B (if they’re both wrapping a String) without even temporarily losing the type safety.

[diesieben07]

But you are calling String methods on InlineClass. Is that not using InlineClass where String is expected?

[Marc Knaup]

transparent inline class A(val raw: String)

val a = A("test")
val x: String = a // won't work
val a2: A = a.trim() // works, only modifies .raw, result is still an A

[diesieben07]

In my opinion that looks a lot like the "scala-like magic" that Kotlin explicitly tries to avoid.

[cbruegg]

So a transparent inline class would not be assignable to a variable of the underlying type, but magically it can become the receiver for a method on that type? Seems very inconsistent to me.

[Marc Knaup]

All it does is to add another level of type safety, somewhere between using raw String everywhere (no safety at all) and an inline class (completely isolated) which requires plenty of wrapping and unwrapping for even basic operations like a.length

[Marc Knaup]

@cbruegg side-effects due to becoming the receiver should indeed be evaluated. Not sure yet what the implications are here.

[raulraja]

I think what you are proposing has the same shape of what in Scala is called implicit conversions which everyone in the community think is largely the source of a lot of bugs. It's actually the reason why Scala implicits have bad press even though many other implicit features are fine and most people that rage about implicits are frequently talking about magic implicit conversions and not compiler proof injection when resolving dependencies.

[raulraja]

May be more problematic if something like this was allowed:

val a: A = "test"

In this case having an inline class as proof of relationship between A and String hides that there is a magic type conversion in call sites and causes confusion.
We already have delegates acting the way you propose, the issue is that String is final. But dispatching method to a value in a class is something Kotlin already does with by so I think a good controlled transparent feature is not bad and inline with Kotlin if it disallows implicit connversions