does cast make an lvalue appear to be an rvalue

[monarch_dodra]

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.