What happened to the "mutable struct" debate?

[Vitaly Davidovich]

Ah, you're talking about *readonly* interaction (I thought you meant dot
notation in general).  Well, this is specific to readonly struct fields,
and that's why myStructArray[i].X = 10 actually mutates the X member of the
struct and not of a copy (the values in the array are not readonly,
obviously).  It's just that with *readonly* struct members in a class C,
C.struct *always* returns a copy.

Yes, there are subtleties involved, and that's why mutable structs are
*not* preferred, but forbidding them outright is a bit draconian (IMHO).

They (MSFT) could've decided to not give this treatment to readonly structs
though, and I'm not sure why they did it this way other than to perhaps fit
their general CLI spec:

..if the field is readonly and the reference occurs outside an instance
> constructor of the class in which the field is declared, then the result is
> a value, namely the value of the field I in the object referenced by E.



On Fri, Jan 23, 2015 at 11:25 AM, Rezaei, Mohammad A. <
Mohammad.Rezaei at gs.com> wrote:

> Sorry, I’m not a C# practitioner, but I’ve been reading about it because
> they supposedly had issues with mutable structs.
>
>
>
> According to
> http://blogs.msdn.com/b/ericlippert/archive/2008/05/14/mutating-readonly-structs.aspx
> , “accessing a value type gives you a COPY of the value. When you say
> t.m, you get a copy of whatever is presently stored in m”
>
>
>
> That sure sounds like Dot is a copy.
>
>
>
> Thanks
>
> Moh
>
>
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* Friday, January 23, 2015 11:17 AM
> *To:* Rezaei, Mohammad A. [Tech]
> *Cc:* valhalla-dev at openjdk.java.net
> *Subject:* RE: What happened to the "mutable struct" debate?
>
>
>
> Also, dot is not a copy in C# unless I'm missing your point.
>
> sent from my phone
>
> On Jan 23, 2015 11:12 AM, "Rezaei, Mohammad A." <Mohammad.Rezaei at gs.com>
> wrote:
>
> I don’t believe this is confusing. It’s not confusing with Java objects.
>
>
>
> MyObject foo =  new MyObject();
>
> foo.inField = 10;
>
>
>
> vs.
>
>
>
> MyObject foo = new MyObject();
>
> int x = foo.intField;
>
> x = 10;
>
>
>
> The rules are simple and the exactly the same as regular primitives:
>
> -          Assignment is copy.
>
> -          Pass into method is copy.
>
> -          return from a method is copy.
>
> -          dot  (.) is not a copy.
>
>
>
> Incidentally, I’m not a C# expert, but I believe the 4th rule doesn’t
> apply there and it causes much confusion.
>
>
>
> Thanks
>
> Moh
>
>
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* Friday, January 23, 2015 11:06 AM
> *To:* Rezaei, Mohammad A. [Tech]
> *Cc:* Brian Goetz; valhalla-dev at openjdk.java.net
> *Subject:* Re: What happened to the "mutable struct" debate?
>
>
>
> Also, here's another thing to consider for mutable structs:
>
> MyStruct[] arr = ...
> arr[i].intField = 10;
>
> Vs
> MyStruct[] arr = ...
> MyStruct s = arr[i];
> s.intField = 10;
>
> These wouldn't have the same semantic yet not super obvious to some from
> cursory glance (or innocent refactoring).
>
> sent from my phone
>
> On Jan 23, 2015 11:00 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
>
> If mutable structs are not allowed to be passed by ref, then one is more
> likely to lose writes as the struct is passed through a method chain.
> There's no *necessity* per say, but the danger zone is expanded.
>
>
>
> The by-ref would be useful for immutable structs as well when you want to
> avoid copying costs for a largish struct.
>
>
>
> On Fri, Jan 23, 2015 at 10:54 AM, Rezaei, Mohammad A. <
> Mohammad.Rezaei at gs.com> wrote:
>
> >Very much so.  This is indeed Big Strike #1 against them; this is a new
> >big complexity that Java (platform and developers) have not had to deal
> >with.
> >
>
> I don't really see why mutable structs would necessitate pass by
> reference. Java developers are used to pass by value semantics and there is
> a well-known, but admittedly ugly pattern for pass by reference (use an
> array or mutable wrapper).
>
> The reference question comes up even in all-final value types. But I'll
> pose that question in a separate thread.
>
> Thanks
> Moh
>
>
>