On Mon, Aug 5, 2019 at 2:10 AM RazvanN via Digitalmars-d <digitalmars-d@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@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)`?

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 ;)

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@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@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 ;)

On Tue, Aug 6, 2019 at 12:55 AM RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> 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@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@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.

👍

On Tuesday, 6 August 2019 at 07:53:25 UTC, RazvanN wrote:
> 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
>     }
> }

Makes sense.

By the way, weird edge cases like that are why I like Rust's semantics (there's no constructor, just struct initialization and factory functions).

Too bad there's no non-painful way to implement them in D at this point.

On Tuesday, 6 August 2019 at 08:35:29 UTC, Olivier FAURE wrote:
> On Tuesday, 6 August 2019 at 07:53:25 UTC, RazvanN wrote:
>> 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
>>     }
>> }
>
> Makes sense.
>
> By the way, weird edge cases like that are why I like Rust's semantics (there's no constructor, just struct initialization and factory functions).
>
> Too bad there's no non-painful way to implement them in D at this point.

Can you not just write trivial constructors (or no constructor, if struct literals are good enough for the case in question) and then use factory functions if you want behaviour like that?

On Tuesday, 6 August 2019 at 09:42:09 UTC, John Colvin wrote:
> Can you not just write trivial constructors (or no constructor, if struct literals are good enough for the case in question) and then use factory functions if you want behaviour like that?

Let met try it...

Oh yeah, actually you can. D even does return value copy elision and everything.

On Tuesday, 6 August 2019 at 16:20:24 UTC, Olivier FAURE wrote:
> On Tuesday, 6 August 2019 at 09:42:09 UTC, John Colvin wrote:
>> Can you not just write trivial constructors (or no constructor, if struct literals are good enough for the case in question) and then use factory functions if you want behaviour like that?
>
> Let met try it...
>
> Oh yeah, actually you can. D even does return value copy elision and everything.

In combination with D's "private means module-private" you can initialise immutable private members this way, so I'd say you're sorted.