Immutability of class and boxed enum instances is not enforcable

[maddanio]

Mutability in jakt is modeled around value semantics, i.e. if one copies an immutable value such as a number or a struct instance the copy can be mutable:

let a = 1
mut b = a
b = 2

which is totally fine. However classes and boxed enums have reference semantics, so chaning the "copy" will also changed the "copied" value, because it was not in fact copies. To fix this two things would have to be changed:

• it should not be allowed to assign an immutable instance to mutable variables
• for function return values of boxed enum or class type it should be possible to declare them immutable.

for the latter again I see three possibilities

• add a const qualifier for return types
• make class/boxed enum return values immutable by default and allow making them mutabke explicitly by adding a mut qualifier
• infer mutablity from whatever is returned

the latter could actually be combined with one of the other two

To really make using immutable instances safe imho it would have to be guarantueed that all variables holding a reference to an instance are immutable. That means either an instance would have to be immutable at construction time and then it should also not be possible to assign it to a mutable variable. or assigningments chaning mutability would have to assert that the reference count is 1.

[maddanio]

alternatively jakt could model c++ in allowing mutable class references to be assigned to immutable variables. that would mean

• allowing function returns of class "values" to be declared const
• not allowing immutable class "values" to be assigned to mutable variables

[maddanio]

regarding the first point jakts "safety by default" design guide i would assume that class "values" would be const by default and would have to be declared mut:
mut myclass function foo()...

[ADKaster]

const return values are meaningless in C++, so it would be difficult to enforce any sort of const correctness that way in either the generated C++ code or any external C++ code calling jakt directly.

Correct reference semantics of class and boxed types is definitely an area that could use improvement though, in more ways than this particular issue.

[maddanio]

const return values are meaningless in C++, so it would be difficult to enforce any sort of const correctness that way in either the generated C++ code or any external C++ code calling jakt directly.

They are not meaningless i the way i mean. So the thing is class "values" in jakt are actually shared Pointers, i.e. have reference semantics. In that case there are two things that can be const: the reference and the referenced instance, in jakt that is currently treated together it seems, i.e. if you have an immutable variable of class "value" you can neither change the reference nor the referenced value. So if you do the same for function returns it would mean that returning "const class values" mean you cannot use this to change the referenced class instance. And that is definitely needed to enforce immutability of class instances.

Correct reference semantics of class and boxed types is definitely an area that could use improvement though, in more ways than this particular issue.

Can you elaborate?