Hi all, just a general design choice question about value classes. If I create a value class, I am only allowed to have exactly 1 constructor parameter. If I then use this type, I still have to treat it as a class with a variable. If the compiler knows Foo only has 1 variable, and it knows its type. why does the compiler make me use myFoo.value instead of just myFoo?

@JvmInline
value class Foo(val value : Int) {
}

//This doesnt work
fun bar(myFoo : Foo) : Int{
   return myFoo + 1
}

//This works
fun bar(myFoo : Foo) : Int{
    return myFoo.value + 1
}

Because the point of a value class is to make a lightweight new type, not a type alias.

The purpose of value classes is to create a new type, generally to avoid confusion (passing around Ints or Strings can be fragile); as such, the compiler sees two types:

Foo

, for your value class, and

Int

, for Foo.value.

Well, the thing is.. I kinda would like it to be a type checked class, with the convenience of an alias

there’s no direct way to convince the compiler that

Foo

(value class) is an

Int

(value type), as there are two types in play. You can dereference

.value

and/or provide operators or other convenience/extension methods to make usage of

Foo

more idiomatic for its value type.

I know i can do custom operators for this 🙂 I was just wondering, isnt it basically polymorphism, as in a Foo is also an Int (since the value class Foo can be identified by its value, which is an Int) (im just basically thinking out loud/ theory crafting)

that’s the point of value types - to distinguish based on type. Otherwise, a method like

something(a: Int, b: Int)

could be called with

Foo

transparently, which puts you back at type aliases.

not really

how so?

since somthing(a : int, b : Foo) could then be called with something(1, Foo(5))

partial relaxation of types safety sounds messy and frought with problems.

basically

@JvmInline
value class Foo(val value : Int) {
}


fun bar(a : Int, b : Foo) =  a + b

bar(1, Foo(2)) // would work
bar(1, 2) // would not work
bar(Foo(1), Foo(2)) // would work

Unless I am mistaken, a value class's parameter and/or constrictor can be private (to effectively hide the underlying type in the API) which would not play well with what you propose.

That bit would still apply right? This is basically only replacing myFoo.value with myFoo. So the only thing it would really effect is where you are interested in myFoo instead of the value inside of it

That would still reveal the underlying type in the API, which is exactly what private doesn't mean.

Well, if it's private, I would not write myFoo.value anyway

I would also say it doesn't make sense semantically. If I have a value class of exit code with an underlying

Int

for the sake of POSIX compliance, allowing

fileNotFound + 1

is nonsense.

Well, if I want to do + 1.. it doesn't stop me from doing ExitCode.value +1

The whole idea behind value classes is to avoid mistakes like adding a temperature value to a pressure value. But you could use

@JvmInline
value class Foo(val value : Int) {
    operator fun plus(i: Int): Int {
        return value + i
    }
}

I'm aware it's possible.. but after a good other discussion what I'm basically looking for is a restricted type (without the disadvantages of a wrapper). As in, e.g. I want to have an int that only contains even numbers. It's more of a thought experiment than how to model it in kotlin, and Kotlin would get really close to it with the suggestion I made.

and a

value class Even(value: Int)

with appropriately overloaded operators would not accomplish that? Of course, you would still not get a compile error for

Even(3)

unless you use something like

@JvmInline
value class Even private constructor(val value : Int) {
    companion object {
        fun ofTwice(i: Int) = Even(i * 2)
    }
}

I am fully aware I can operator overload or just call .value on it. But the whole point was more that it seems a bit boilerplateish. Basically it's indeed a implicit type conversion (basically autoboxing) that should be fully type safe.

so you are arguing that

1 + Apple(2) + Orange(3)

should result in

6

?

if Apple and Orange are both value types which are fully identified by their Int mapper, then yes

not in my book: I would never add apples and oranges (or meters and feet) w/o explicit control. The whole point I see in value classes is to get the runtime efficiency w/o the type safety issues. Else, why not just use type aliases?

But you can still do Meter(1).value + Feet(1).value, and that will just compile

I think we have to agree to disagree here, because I really do not see any point in your

m + f

.

the point is more that fun divide(a : int, b : NotZero) = a /b is quite nice

so could be

"hello" + 3 == "hello3"

, but I still think the gain does not justify the potential pain (esp. given that I can always implement this if I really want to). Anyway, OO for me now

Kotlin actually supports that

fun doSomething(m : String, f:  Int ) : String = m + f

`

I would like to add that I think @Ties’s use case is legitimate. For instance, a

value class Positive

could arguably be useful as its underlying int since it only refines the type. Maybe this should be a new language feature? In fact, I suggested a while back the idea of

transparent value class

which would be considered both its own type but also its underlying type: https://kotlinlang.slack.com/archives/CQ3GFJTU1/p1629640887047500 https://kotlinlang.slack.com/archives/CQ3GFJTU1/p1629640887047600

Sometimes other languages can be useful for bringing ideas to a new language. Ada has a strong type system in which you can refine the primitive types, so you could indeed have a type called Positive, for example. This snippet gives a flavour of what it's like:

procedure Main is
   type Distance is new Float;
   type Area is new Float;

   D1 : Distance := 2.0;
   D2 : Distance := 3.0;
   A  : Area;
begin
   D1 := D1 + D2;        -- OK
   D1 := D1 + A;         -- NOT OK: incompatible types for "+" operator
   A  := D1 * D2;        -- NOT OK: incompatible types for ":=" assignment
   A  := Area (D1 * D2); -- OK
end Main;

Correct me if I'm wrong, but this seems to be the exact opposite of what @Ties is asking for. This shows a sub type that cannot be mixed, whereas they're asking for a new type that can be mixed.

Well, my use case was actually not mentioned in the last post, distance and area are 2 separate types, but I suggested that a function that can have a float as input could also have a distance as input

I think that basically with something like a

transparent value class

(having a keyword like transparent makes it very explicit which is good) maybe we can consider that value class to just be a subtype of its underlying value. And so, in a way, Foo would be a subtype of Int, and so, just like a normal subclassing relationship, if

Foo + Int

is not defined,

Int + Int

will be used instead.

Indeed :) so Foo + Int won't produce a Foo, but will produce an Int (since that's the closest common type)

And obviously you then could, if wanted, to define a

Foo + Int

that returns a

Foo