On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
How do you propose to make a mutable copy *generically*?
You can't. Let alone generically.
If I give you an "immutable int* p", how do you copy it to "int*
p" ?
On Wednesday, 16 October 2013 at 18:11:48 UTC, Daniel Davidson
wrote:
Thanks. It is cute - but not so helpful. The example stands. I
*need* to call a createRFromT.
Their shapes are the same in this simple example because I
simplified. Make R look like:
struct R {
string[string] ss;
int[] j;
}
and the cute trick falls apart. In words, I have an R and I
want to make a T. The R is const the T will be immutable
because the ctor requires it. But it is technically not
immutable until it is initialized.
The problem is that you are taking a const(R). And you can't
assign a const to an immutable. It has nothing to do with
initialization.
Remember: "const" means *you* promise not to modify the value,
whereas immutable means *no one* will modify it ever. Because of
this, you can't assign a const to an immutable.
For example:
int[] a = [1];
const(int)[] c = a; //Legal
immutable(int)[] i = c; //Forbidden
If that assignment passed, think of what would happen if I wrote:
a[0] = 5;
On Wednesday, 16 October 2013 at 18:14:22 UTC, Daniel Davidson
wrote:
I agree with the sentiment. But as it stands I think a copy
should not be necessary. I could make a local mutable R, pass
it to createRFromT to get it initialized and then copy it back
somehow to the member variable r. That to me is silly. The copy
should not be required.
A copy *might* not be necessary provided building an immutable
copy from mutable is actually legal. This is not your case.
What you are doing is warping the type system.
