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?
