copy constructors need documentation

[RazvanN]

On Tuesday, 6 August 2019 at 01:30:30 UTC, Manu wrote:
> On Mon, Aug 5, 2019 at 2:10 AM RazvanN via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Monday, 5 August 2019 at 09:01:39 UTC, Manu wrote:
>> > On Mon, Aug 5, 2019 at 12:55 AM RazvanN via Digitalmars-d 
>> > <digitalmars-d at puremagic.com> wrote:
>> >> [...]
>> >
>> > I'm so sorry, I completely missed that section of doco. It's
>> > actually
>> > quite comprehensive.
>> > I don't know why I didn't find it initially when I went 
>> > looking.
>> > Somehow the organisation didn't get me there.
>>
>> No worries!
>>
>> > It's a very tough read though, I had to jump around a lot;
>> > like, I was
>> > trying to work out why a qualified constructor works, and 
>> > that's
>> > detailed in another section (which I still don't understand;
>> > how can I
>> > assign to an immutable `this`), but yeah, sorry for the false
>> > alarm!
>>
>> Long story short: that's basically initialization of an 
>> immutable `struct`, therefore it is allowed. What I find weird 
>> is that you can define opAssign on `immutable` objects (wtf?!).
>
> So it's mutable for the time during initialisation?
> `typeof(this) == T`?? not `immutable(T)`?
>
No. typeof(this) is going to be immutable(T) and `this` cannot be 
modified
as in `this = something`, but the first assignment of each of 
this's field
is considered initialization and allowed:

struct T
{
     int a;
     this(int a) immutable
     {
         pragma(msg, typeof(this));    // immutable(T)
         this.a = a;                   // ok, even though this.a 
is immutable
     }
}

Since this makes sense for constructors, it also makes sense for 
copy constructors as you may initialize an immutable object from 
a mutable one.

> Yeah that opAssign thing is odd... perhaps you can pin some 
> dynamic
> metadata against an immutable thing via some side channel? 
> ...perhaps
> it seems reasonable to do that via assignment?
> I have no idea ;)