opDispatch and compile time parameters

[Jonathan M Davis via Digitalmars-d]

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