Clarification on migration to value types and boxed vs unboxed representations

[Brian Goetz]

If your comparison is that "mutable structs are like unsafe", great -- 
that's a bulletproof argument that value types must not be mutable, and 
there is no need for further discussion on the topic :)

(Pause while Brian gets out his chisel to carve it in stone....done.)


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