Someone needs to write up the documentation for copy constructors.
There's no source on how to write them, and explaining how to handle
all the different qualifier cases and such.
Currently, you have to troll through threads and try and interpret a
DIP to work it out... it's not good enough. A user wouldn't even know
D has copy constructors by looking at the language reference on
dlang.org.

On 08/04/2019 03:16 PM, Manu wrote:
> Someone needs to write up the documentation for copy constructors.

... so that I can update "Programming in D". I haven't followed the original discussions, did not understand the DConf presentation fully, do not know all interactions with postblit, etc. Help! :)

Ali

On Sun, Aug 4, 2019 at 6:35 PM Ali Çehreli via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 08/04/2019 03:16 PM, Manu wrote:
> > Someone needs to write up the documentation for copy constructors.
>
> ... so that I can update "Programming in D". I haven't followed the original discussions, did not understand the DConf presentation fully, do not know all interactions with postblit, etc. Help! :)

Exactly!

One of these days, Andrei is gonna need to update his book too...

On Sunday, 4 August 2019 at 22:16:05 UTC, Manu wrote:
> Someone needs to write up the documentation for copy constructors.
> There's no source on how to write them, and explaining how to handle
> all the different qualifier cases and such.
> Currently, you have to troll through threads and try and interpret a
> DIP to work it out... it's not good enough. A user wouldn't even know
> D has copy constructors by looking at the language reference on
> dlang.org.

There is this documentation [1] that covers most of the aspects. I didn't write too much about qualifiers in that documentation because existing overloading and implicit conversion rules apply (as stated in the DIP).

Can you point out explicitly what you think is vaguely explained?

[1] https://dlang.org/spec/struct.html#struct-copy-constructor

On Mon, Aug 5, 2019 at 12:55 AM RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 4 August 2019 at 22:16:05 UTC, Manu wrote:
> > Someone needs to write up the documentation for copy
> > constructors.
> > There's no source on how to write them, and explaining how to
> > handle
> > all the different qualifier cases and such.
> > Currently, you have to troll through threads and try and
> > interpret a
> > DIP to work it out... it's not good enough. A user wouldn't
> > even know
> > D has copy constructors by looking at the language reference on
> > dlang.org.
>
> There is this documentation [1] that covers most of the aspects. I didn't write too much about qualifiers in that documentation because existing overloading and implicit conversion rules apply (as stated in the DIP).
>
> Can you point out explicitly what you think is vaguely explained?
>
> [1] https://dlang.org/spec/struct.html#struct-copy-constructor

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

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?!).

On Monday, 5 August 2019 at 09:07:17 UTC, RazvanN 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?!).

I believe that the reason behind it is that you can't modify an immutable instance,
so defining `opAssign` for `immutable` types wouldn't be of any use.

Probably the same should go for `const`.

The curious case is that you can actually define the operator, but you can't call it
https://run.dlang.io/is/RE0g9S

I've never written a qualified `opAssign` based on the reasoning above and, imho, it holds water.

On 05.08.19 14:27, Eduard Staniloiu wrote:
> I believe that the reason behind it is that you can't modify an immutable instance,
> so defining `opAssign` for `immutable` types wouldn't be of any use.
> 
> Probably the same should go for `const`.
> 
> The curious case is that you can actually define the operator, but you can't call it
> https://run.dlang.io/is/RE0g9S
> 
> I've never written a qualified `opAssign` based on the reasoning above and, imho, it holds water.

An immutable opAssign doesn't seem particularly useful, but it's also not unsound by itself.

Or is there a good reason why the following shouldn't work?

----
int x;
struct S
{
    void opAssign(S rhs) immutable { ++x; }
}
void main()
{
    immutable S s;
    s = s;
}
----

On Monday, 5 August 2019 at 12:42:34 UTC, ag0aep6g wrote:
> Or is there a good reason why the following shouldn't work?

Well, it's a crime against understandable code and against reason itself, but it's not strictly *unsound* per se.

On Monday, August 5, 2019 7:33:19 AM MDT Olivier FAURE via Digitalmars-d wrote:
> On Monday, 5 August 2019 at 12:42:34 UTC, ag0aep6g wrote:
> > Or is there a good reason why the following shouldn't work?
>
> Well, it's a crime against understandable code and against reason itself, but it's not strictly *unsound* per se.

Really, it comes down to whether it's worth special-casing it to make it illegal. The type system itself prevents a const or immutable opAssign from doing something that they shouldn't (barring casts which involve undefined behavior anyway), and realistically, no one is going to define them anyway. So, while really, they shouldn't ever be declared, the fact that they can be shouldn't actually be a problem.

- Jonathan M Davis