Clarification on migration to value types and boxed vs unboxed representations

[Brian Goetz]

The C# folks concluded in hindsight that mutable structs was a big 
mistake.  See Eric Lippert's blog:

http://blogs.msdn.com/b/ericlippert/archive/2011/03/14/to-box-or-not-to-box-that-is-the-question.aspx

TL;DR version (last line): "Once again the moral of the story is: 
mutable value types are enough pure evil to turn you all into hermit 
crabs, and therefore should be avoided."




On 1/6/2015 8:33 AM, Vitaly Davidovich wrote:
> 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 joda.org> wrote:
>
>> On 6 January 2015 at 01:58, Vitaly Davidovich <vitalyd at gmail.com> 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
>>