``` typealias UserId = String class User(val id: U...

# language-proposals

[mg6maciej]

typealias UserId = String
class User(val id: UserId)
val myString: String = "blabla"
User(myString) // wouldn't compile

[benleggiero]

How would this be advantageous over a wrapper- or sub-class?

[mg6maciej]

Wrapper as in class UserId(val value: String)?

[benleggiero]

Yes

[mg6maciej]

Almost none. Except for less memory use.

[mg6maciej]

And maybe if you have it serialized to json, you don't need to write custom converters to skip one "layer" and send / receive id directly as string.

[benleggiero]

Maybe. Sounds like it'll lead to confusion.
"I can assign a String to a var of type UserId, but I can't pass a String to a function that takes one?"

[mg6maciej]

In real code you would probably almost never had a case of assigning String constant to a var/val.

[mg6maciej]

So if you have a ClientId instead of String or Long and if you have it in Purchase table as FK and Client table as PK, you will never pass ProductId (also String or Long) to function findClientById(ClientId), which you get from Product.

[benleggiero]

I see the need, but I can't imagine it'd ever work intuitively. If anything, it will just make the language more difficult to use. There would have to be very consistent rules about what will work where and what won't.

Also these would break my system where I have an abstracted set of aliases like:

typealias Int64 = Long
typealias Integer = Int64

so I'd now no longer be able to pass a Long literal to a function that takes an Integer? Or something like that?

[sreich]

Maybe there could be a casting mechanism?

[sreich]

I've thought about your newtype for entity id, which is just an int... But at some point you need to switch over