How to break const

[Era Scarecrow]

On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
> On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
>>> So (**IMHO**) if that's really the case, we should really 
>>> spend some time fixing the /design/ of const before the 
>>> implementation...
>>
>> This is mostly about the design of object initialisation.
>>
>>> good idea or no?
>>
>> Certainly.
>
>
> My initial instinct would be to require a "const constructor" 
> in order for an object to be const-able, but I'm not sure if 
> that would work correctly or not..

  Hmmm... Reminds me of an issue that ended up coming up regarding 
code I was transforming to use immutable rather than mutable 
data. I kept coming up with the same issues. Without a const 
specific constructor, the immutable data I was basing the 
information off refused to go to a mutable temporary (since I 
needed it to be mutable), even if the end object was immutable 
and the data was untouched.

  I ended up with having to make a separate function that acted as 
a constructor, copying immutable elements and data as needed as 
mutable, then passing it back as immutable afterwards. A little 
ugly but it got the job done.

  I also came across an interesting problem.

struct X {
     immutable int i_i = 10;
     const int c_i = 10;   //same with immutable

     immutable int i_i2;
     const int c_i2;

     this (int n) {
         i_i = n; //ct error
         c_i = n; //ct error

         i_i2 = n;
         c_i2 = n;
     }
}

void main(){
     X x = X(15);
}

  In this case it refuses to modify i_i & c_i during the 
constructor, the value of i_i & c_i specify is basically a 
replacement default(init) and should remain mutable until the 
constructor is finished (Or at least allowed to set once). If I 
wanted a strictly unchanged value I probably would have used an 
enum, and not used the space.

  Is this a bug or intentional?