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.

On Wednesday, 16 October 2013 at 19:49:25 UTC, monarch_dodra wrote:
> 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" ?
>

That was my point.

> 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.
>

No I don't think I am. What code are you looking at?

>
> 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.

Based on your previous comment, I don't think you understood the setup.

On Wednesday, 16 October 2013 at 19:49:25 UTC, monarch_dodra wrote:
> 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.

Just to clarify: in the code below: createRFromT(t, r) is *not* meant to imply it will just try an  assignment. Rather, it reads from t and builds its own data for R. The problem is with initialization - see Simen Kjaeraas response here: http://forum.dlang.org/post/mailman.2241.1381953340.1719.digitalmars-d-learn@puremagic.com

struct S {
  R r;
  this(ref const(T) t) immutable {
    createRFromT(t, r);
  }
}

void createRFromT(ref const(T) t, ref R r) {
  //...
}