Clarification on migration to value types and boxed vs unboxed representations

Vitaly Davidovich vitalyd at
Tue Jan 6 13:33:41 UTC 2015

What are the "far too many" downsides? The lost writes can happen if not
careful, but what else? I'm assuming though if mutable value types were
possible, then language and VM would allow passing them by ref.

Sent from my phone
On Jan 6, 2015 5:12 AM, "Stephen Colebourne" <scolebourne at> wrote:

> On 6 January 2015 at 01:58, Vitaly Davidovich <vitalyd at> wrote:
> > Mutable structs aren't used all that often in c# but there are times when
> > they're very useful.
> When I've thought about this, the first use case for mutable I came up
> with was property objects. These allow code like:
> class Person {
>   public final Property<Strring> surname;
> }
> String surname = person.surname.get();
> person.surname.set("MySurname");
> Property<String> p = person.surname;
> Here, Property is a mutable wrapper around the surname, hence the
> get() and set(). Today, this design is only suitable for the client
> side, as creating all the wrapper objects creates far too much garbage
> and churn for a server (tried it, was a car crash).
> However, despite the appeal of making this work via value types, I'm
> willing to agree that allowing mutability would have far too many
> otehr negative consequences. Thus I agree with the "only immutable"
> design direction.
> Stephen

More information about the valhalla-dev mailing list