On Tuesday, 20 October 2015 at 11:36:36 UTC, Marc Schütz wrote:
On Tuesday, 20 October 2015 at 01:49:08 UTC, Jonathan M Davis wrote:
On Monday, 19 October 2015 at 23:37:09 UTC, Timon Gehr wrote:
This is the worst part:

class C{
    int[] x=[1,2,3];
}

void main(){
    auto mut=new C;
    auto imm=new immutable(C);
    assert(imm.x[0]==1);
    mut.x[0]=2;
    assert(imm.x[0]==2);
}

Oooo. Ouch. Yeah, that pushes it from being a good idea to disallow this in order to avoid bugs to a necessity to disallow it in order to avoid breaking the type system.

Yeah. But IMO it should still be allowed for immutable objects, and the error/deprecation message should say so, because for those it can actually be useful and there would be no other way to do it.

I believe that it's supposed to be possible to initialize an immutable member variable in a struct's constructor. So, the only thing that allowing member variables that are immutable objects or arrays to be directly initialized would add would be to make it so that they can be part of the init value. And in general, I'd strongly argue that it's bad practice to have either const or immutable member variables in a struct, because then it can never be assigned to even if the struct as a whole is supposed to be mutable. But that's a problem with member variables in general, not just those which refer to objects on the heap, so disallowing directly initializing with immutable objects/arrays on that basis wouldn't make sense IMHO. It just means that in most cases, it would be a bad idea for different reasons.

What I _do_ think is useful is having a member variable which is Rebindable so that it refers to an immutable object but isn't actually immutable itself (SysTime is supposed to do that but can't at the moment due to a compiler bug). But regardless, having a member variable directly initialized with an immutable object or array should be safe and correct. So, I agree that we should allow it. const could be depending (though it's probably easier not to), but mutable definitely has to go.

- Jonathan M Davis

Reply via email to