A modern programming language that makes developers happier.

kotlinlang

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 guess it works for classes like UInt which have all useful functions defined in their class so you'll rarely ever need the raw value, but I guess even UInt has toInt function which just returns the data

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.

But I would ask the questions the opposite way. What would be the benefit of breaking usual assignment rules (and adding implicit subtyping), apart from saving you from typing `.value`. I believe accessing the inner value should be rare enough when using value types

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