https://kotlinlang.org logo
#language-evolution
Title
# language-evolution
d

Davio

10/14/2023, 9:51 AM
Has it ever been considered to allow auto unboxing for value types? E.g.
Copy code
value class MyInt(val value : Int)
val actualInt: Int = MyInt(1)
j

Joffrey

10/14/2023, 10:13 AM
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
4
d

Davio

10/14/2023, 10:49 AM
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
j

Joffrey

10/14/2023, 10:51 AM
The wrapped value is not necessarily public, so it's not already possible to use it everywhere the wrapped type is used
d

Davio

10/14/2023, 11:02 AM
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
j

Joffrey

10/14/2023, 12:04 PM
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
d

Davio

10/14/2023, 2:33 PM
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
j

Joffrey

10/14/2023, 8:41 PM
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
1
l

Loney Chou

10/14/2023, 11:59 PM
Value classes will be able to declare multiple fields, so on this aspect it also doesn't make sense.
d

Davio

10/15/2023, 9:39 AM
Ah when Valhalla comes along you mean, yeah then this doesn't make sense anymore