Has it ever been considered to allow auto unboxing for value types? E.g.

value class MyInt(val value : Int)
val actualInt: Int = MyInt(1)

I believe one of the major goals of defining a value type is specifically to forbid this, to define a completely separate type for safety purposes

I understand but I would think it goes just one way, not the other, ie a MyInt is an Int, but an Int is not a MyInt. To me it feels like a value type is just like a subclass of the type it wraps. It is already possible to use a value type everywhere you could use the wrapped type by accessing its value, so this would just be shorthand and would just turn

realInt = myInt.value

into

realInt = myInt

The wrapped value is not necessarily public, so it's not already possible to use it everywhere the wrapped type is used

Hmm I guess that's true though I wonder how useful that is

I use this approach for an

Amount

class representing money, abstracting away the multiplatform big decimal type. All necessary operations are defined on it, but I don't want the value to be exposed so I can swap the underlying type as needed. And also I want to make sure operations are done in a certain way, and that we can't do it directly on the big decimal. Only formatting operations and a lossy conversion to

Double

(for use in charts) are exposed. And of course using this type separates it from pure "fractions" or "rates", which are similarly backed by big decimals.

Hmm we use the value type as a domain type, but DTO's for REST or the database still need an actual type so I guess it's mostly all the mapping stuff and I think it had a non intuitive toString since it also outputs the type instead of just the wrapped value so when we log it, we often use the actual value

Then maybe this is a symptom that it is not entirely considered a new type in your code base. Your rest DTOs could serialize it with its own serializer (that's one usage), and the DB as well could have a custom type converter for this type (second usage). That's really not many places requiring

.value

. And if you don't want logs to distinguish this type from the wrapped type, you could override

toString

, which doesn't require accessing

.value

from the outside

Value classes will be able to declare multiple fields, so on this aspect it also doesn't make sense.

Ah when Valhalla comes along you mean, yeah then this doesn't make sense anymore