Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

I was merely using unsafe as an example of a tool (lib, not language, in
this case) that's (relatively) rarely used, but very important for some
cases.  If you want to provide a Sufficiently Smart Compiler that makes it
obsolete, great, but that's not here presently and probably never will be
(it'll be good enough for majority of cases though).

One thing that really irks me (and I think some others, based on my
observations) about some of the discussions around java and its direction
is the sentiment that java developers require hand holding, can't be
trusted, must be fully abstracted away from the machine, and thus deserve a
language with *mandatory* safety belts and restraints.  If java wants to
stay relevant in high perf domains, that sentiment needs to be dropped;
escape hatches/unsafe-ish code must remain available.  Every language that
I know of which markets itself as being relevant in high perf scenarios
allows for having small targeted amounts of unsafe code; there's absolutely
nothing wrong with that, and in fact, it's a Good Thing.

As for mutable value types, showing developers the types of issues they may
face is fine, direct them towards immutability, but ultimately, let them
decide! (clearly, mutable value types aren't going to be implemented, I'm
not going to change your mind, but I dislike the philosophy behind it).

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

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