Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

I've seen and read that blog before.  I'm not disputing that one needs to
be careful in how C# mutable structs are used and as mentioned, it's a rare
(but useful) use case.  But really, the issue in that blog is more about
how compiler desugars/transforms C#'s using block and its poor interaction
with value types when someone doesn't fully understand the sugaring
mechanics.  I suspect the problem Eric (when he was still at MSFT) had was
developers not taking the time to fully understand the tool.  Yes, it's
error prone if you're sleep walking through code, but then again, don't
sleep walk through code!

So, I'll agree that their use should be restricted, but it's nice to have
when needed (akin to using com.sun.misc.Unsafe -- it's a sharp knife that
can inflict serious damage if not wielded carefully, but very
handy/surgical when called for and used carefully).

On Tue, Jan 6, 2015 at 10:13 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>>>
>>>