[New DIP] Copy constructor

[RazvanN7]

No description provided.

[wilzbach]

Typo: implicit

[mdparker]

So, a reminder for anyone reading this thread who is considering a new DIP:

The DIP Author should not submit a pull request to the DIP Repository until the first draft is complete. The DIP Repository is not the place for the initial development of a DIP. The DIP Author(s) should develop the first draft of the DIP in the newly forked repository. A completed first draft is one that, if it were perfect and required no further revision, would be ready to proceed through the entirety of the DIP process.

https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#development-stage

[atilaneves]

To me this looks weird when += exists.

[atilaneves]

s/aquire/acquire/

[atilaneves]

Why not something similar to C++? It's not even discussed here. Also, making the syntax a link to somewhere else makes it harder to read when it's an important part of the DIP.

[RazvanN7]

The link is added in order to show exactly what the changes to the grammar are and also because there is no nice way to explicitly express the grammar in the md format.

[atilaneves]

It makes it a lot harder to read and understand what's being proposed.

I still don't understand why such a radical departure from C++ syntax, given that AFAIK is the only language with a copy constructor.

[atilaneves]

This took me a while to understand. It'd probably be best to say that the type of the parameter to the copy constructor needs to be identical to typeof(this).

[atilaneves]

typo on "assignment"

[JohanEngelen]

This section needs reworking. It is irrelevant and confusing to talk about how things were in the past. State what the current problem is.

[JohanEngelen]

the compiler does the following steps

Careful in wording: it is irrelevant what a particular language implementation does. Write things down in terms of semantics. (in this particular case, the compiler isn't doing any of these steps. It is the generated executable that does them)

[JohanEngelen]

same here: simply remove "the compiler will decide that".

[JohanEngelen]

"this way, the first assignment of B.a.a will be considered an initialization."

[JohanEngelen]

reword after removing "compiler"

[JohanEngelen]

"both an alias this and a copy constructor, and for which assignments to variables "
(add comma, and fix spelling)

[JohanEngelen]

note my comment about @implicit breakage.

[JohanEngelen]

It'd be nice to have a discussion of the extra complexities this brings. For example, with this DIP, a = b; may modify b, severely impacting legibility and reasoning. Is it allowed to only declare a copy ctor, @implicit this(ref typeof(this));, such that the implementation is opaque? (e.g. in a .di file)
How can this new language feature be abused?
Etc.

[JohanEngelen]

Mention explicitly somewhere that copy constructors are not proposed for classes.

[JohanEngelen]

I'm sure here you mean that the "destination" is initialized to .init.
If things are the same as the normal constructor, why does this need to be mentioned at all? E.g. what happens if the copy ctor body is not empty?

[JohanEngelen]

Can I also @disable the copy constructor, such that a = b; gives a compile error?

[JohanEngelen]

What is the order of copy ctor calls when a struct contains a struct?

struct A { int a; }
struct B {
   A aaa;
   int b;

  @implicit this (ref typeof(this) rhs) {
      // has `aaa` already been copied with copy-ctor at this point?
   }
}

[RazvanN7]

There is no order, because the user is in charge of copying all the fields of B. If inside the copy constructor there is a line "this.aaa = rhs.aaa", then A's copy constructor will get called (if A defines a copy-ctor)

[JohanEngelen]

I think you should mention somewhere very explicitly that this allows modification of the source.
This means that from now on, a = b; in general might modify b. Do we really want that?

[aliak00]

If it was not wanted then wouldn't the author make another a const ref or?

[RazvanN7]

@JohanEngelen thank you very much for your extensive review!

[nemanja-boric-sociomantic]

Doesn't "Although @implicit looks like a user defined attribute, it is not considered one to avoid breaking user code that already uses it" imply (heh) that this effectively adds a keyword to the language?

[wilzbach]

This will an Markdown document on the web. Can't we use an actual link?

[Python-implementation][python-implementation]
...
[python-implementation]: http:...

There's also no precedent of this style in the other DIPs, is there?

[wilzbach]

Can't we include a diff here, s.t. the DIP is self-contained? (in case the PR gets force-pushed or modified later)

[rainers]

I agree, following the link and looking at the diff mostly displays ddoc noise. Showing the new grammar rules here would be a lot nicer.

[AMalahov]

should type be ref B?

[RazvanN7]

no, it would be an error that way. The type of the copy constructor parameter has to be typeof(this)

[AMalahov]

Hmm... I could swear struct B (in code below) had @implicit this(ref A another) immutable {} and I meant to comment on that :) Probably that code was squashed.

Never mind, now it's OK anyway.

[ntrel]

I've made a pull with some minor tweaks here: RazvanN7#1.

[jacob-carlborg]

Making the @implicit keyword a compiler recognizes UDA would avoid some breaking changes.

[belka-ew]

You mean " copy constructor", don't you?

[belka-ew]

@nogc (with @)

[belka-ew]

section (singular)

[belka-ew]

Dot missing.

[belka-ew]

and "This sections"

[belka-ew]

probably superfluous empty line.

[belka-ew]

Space in the front of colon.

[ghost]

Wouldn't this be a breaking change to require the copy constructor in this case? Right now move semantics are used, so this can be done without a postblit constructor @disable this(this);. Otherwise what rules are going to be used to determine whether a move can simply be done or a copy constructor needs to be called?

struct A
{
    @disable this(this);
    
    int a;
}

A func()
{
    return A(0);
}

void main()
{
    A a;
    a = func(); // ok
}

[RazvanN7]

You are right, the value is moved, but in my example the function returns an lvalue and a call to the copy constructor is issued on callee site. This is explained in the next paragraph.

[ghost]

Yes but why would it do a Copy if it can just do a Move instead? In this instance when the copy constructor is the same type.

[RazvanN7]

The copy constructor may be used for conversions:

struct A
{    
    int[] a;
    @implicit this(ref immutable A rhs) {}
}

A func(immutable A a)
{
    return a;
}

void main()
{
    A a;
    a = func();
}

[rainers]

Why does modifier immutable allow the assignment to mutable a below?

[RazvanN7]

This is indeed a mistake. The types are reversed : a,b,c should be immutable and the r's mutable, const, immutable

[rainers]

I think this will not compose very well with structs that contain legacy fields that have a postblit. Can't the implicitly generated postblit just be omitted instead?

What about the reverse: a struct that has a postblit, but also fields with copy constructor?

[RazvanN7]

It's the same, postblit and copy constructor just can't go together. I've thought about preferring copy constructor over postblit, but the postblitt is essentially broken and must be deprecated. The code that defines a postblit can simply transform it into a copy constructor my changing the declaration.

[rainers]

It is ok that postblit and copy constructor don't coexist in a struct, but fields could still just have a postblit that is used when the copy constructor of the outer struct initializes the field.

[rainers]

missing ;

[rainers]

AFAICT this is a declaration of b, not an "evalution". Did you mean to declare b of type A?

[RazvanN7]

Yes.

[rainers]

How does calling the copy constructor on the return value interact with RVO (return value optimization)? I guess it might be omitted then.

[RazvanN7]

Yes.

[thewilsonator]

Is @implicit really necessary?

Put other ways:
Is the breakage due to the reservation of @implicit worse than modifying the semantics of existing code (especially if transitioned with a -dip10xx flag)?
If someone is declaring a constructor of signature this( ref [qualified] typeof(this) a) [qualified], is there any case that they don't want it to be a copy constructor given that the copy constructor is to replace the postblit (again with transition)?

[jacob-carlborg]

@implicit doesn’t need to be reserved, it can be a compiler recogized UDA.

[thewilsonator]

I'm saying it doesn't need to exist, i.e. @implicit can itself, be implicit under a compiler switch.

[jmdavis]

Honestly, I would expect using @implicit (or any other attribute) for copy constructors would ultimately cause more bugs than it would ever prevent. Very few functions that would qualify as copy constructors if they were marked with @implicit will have been declared in D code at this point, because it really doesn't make much sense to (that's what postblit constructors are for), and if they were declared, does anyone honestly expect them to be intended to work as anything other than copy constructors (albeit ones that must currently be called explicitly)? While not requiring @implicit might break existing code, it's not particularly likely, and long term, it would be far better to have a transitional compiler switch than to require @implicit just for fear of breaking code that is likely to be extremely rare (if it exists at all) and which likely would work perfectly well with the changes anyway.

On the other hand, if we require @implicit, then it's bound to become a common bug to forget @implicit, resulting in code that you think is using a custom copy constructor but in fact is using the default, because you forgot @implicit. So, we're talking about trying to avoid breaking functions that are likely to be extremely rare by using a solution that's pretty much guaranteed to cause plenty of bugs in the future. I agree that we should be trying to avoid breaking exist code, but that tradeoff is just plain horrible. If we don't want to just immediately, silently break extremely rare code, then providing a compiler switch initially like we have with other DIPs would make a lot more sense. It might even make more sense anyway if we want a chance to bang on the implementation of copy constructors first to make sure that they're working properly before forcing them on everyone.

[RazvanN7]

and if they were declared, does anyone honestly expect them to be intended to work as anything other than copy constructors (albeit ones that must currently be called explicitly)

I think that this is a major point in the need of @implicit. When the user defined the constructor (even though it was intended to work as a copy constructor) he/she didn't have any expectation that it would get called implicitly. The fact that the function was designed to be called explicitly is the reason why @implicit is needed.More than that, there might be users out there that want a copy constructor which is called explicitly and one that is called implicitly (I can't think of any use case, but regardless of that, there might be folks that want it); by not requiring @implicit there is no way they can achieve it.

On the other hand, if we require @implicit, then it's bound to become a common bug to forget @implicit

This is mere speculation.

So, we're talking about trying to avoid breaking functions that are likely to be extremely rare by using a solution that's pretty much guaranteed to cause plenty of bugs in the future.

When the people will read the changelog and see that the copy constructor feature is now available, I'm guessing that they are going to read the specification first and so copy construction is going to be associated with @implicit.

Other pros for @implicit:

-> it is a lot easier to spot copy constructors and differentiate them from normal constructors when reading code when you see @implicit
-> it will be easier to extend the feature to copy construct from any type to any type.
-> it brings more clarity (you know that that specific constructor is used implicitly as opposed to an unmarked copy constructor which it's a bit confusing if it is used implicitly or explicitly)

[thewilsonator]

didn't have any expectation that it would get called implicitly.

That is the entire point of the transitional process.

there might be users out there that want a copy constructor which is called explicitly and one that is called implicitly

This is also speculation.

On the other hand, if we require @implicit, then it's bound to become a common bug to forget @implicit
This is mere speculation.

In contrast to all the other attributes they can be ignored and the code is unaffected or the compiler emits an error e.g. I forget nothrow: either is doesn't matter (because the code that calls it is not nothrow), or it is and the compiler complains. With this I forget @implicit`, and the code is wrong and still compiles.

it is a lot easier to spot copy constructors and differentiate them from normal constructors when reading code when you see @implicit

Is it really that much worse than for postblits? Is that even a problem?

it will be easier to extend the feature to copy construct from any type to any type.

Is this a thing we are even considering?

it brings more clarity

It does. Is it needed?

[RazvanN7]

This is also speculation.

It is not speculation, it is something you can do by the rules of the language and it will become impossible if @implicit is dropped.

Is this a thing we are even considering?

Yes.

[aliak00]

Is this a thing we are even considering?
Yes.

💛 !!!

On @implicit: I really like the explicit part of being implicit.

But this analysis:

On the other hand, if we require @implicit, then it's bound to become a common bug to forget @implicit, resulting in code that you think is using a custom copy constructor but in fact is using the default, because you forgot @implicit.

I think will be quite true once you add another part of this DIP:

Whenever an initialization by copying is encountered, a call to a copy constructor is tried
and if a matching copy constructor is found it is used, otherwise if no copy constructor is
suitable, standard copying is employed

Experience says that people forget extra configurations, so this will happen if the compiler does the standard copying by default. People will think they've defined a copy ctor.

Is it possible to only perform standard copying iff an implicit copy constructor is actually declared. This way you'll get a compiler error : cannot implicitly copy type, please add an @implicity copy contructor or something. Is that possible?

Or maybe the postblit makes that a bit difficult :/

I guess a transition flag may help here ;)

[thewilsonator]

It is not speculation,

It is, you missed

there might be users out there that want

(emphasis mine), you also provided no use case for it.

Is this a thing we are even considering?
Yes.

Oh dear (and you thought @implicit was contentious...) . Regardless, that is not part of this DIP; this DIP is replacing something that is implicit (postblit), with something else that is implicit (copy construction).

[jmdavis]

I don't see how anyone could argue that it's not going to be a common thing to forget to use @implicit. It doesn't actually add anything. All it does is turn on the behavior that everyone is going to expect. Sure, over time, folks will get used to it and be better at remembering it, but I can guarantee that many folks will forget it just like they forget other attributes. However, in this case, instead of getting a compiler warning because you did something like call an @system function from an @safe function, because you forgot to mark the function with @safe, you'll end up with the default copying mechanism silently being used instead of your custom copy constructor, which may or may not quickly be caught. So, if we ignore the issue of possibly breaking existing code, all @implicit does is provide us an easy way to have extra bugs.

There really is no reason to be declaring a copy constructor if you don't intend for it to be implicit. So, every copy constructor is going to need the attribute, making it so that it's simply a source of bugs (when it's forgotten) rather than a benefit. The only reason to have @implicit is to avoid breaking code which is almost certainly extremely rare. We've made breaking changes in the past like this by using compiler switches to enable the transition. Why don't we simply do that here as well? I see no benefit to having @implicit over a transitional compiler switch and several negatives. Adding @implicit for fear of breaking rare code just means that we're trying to avoid short term breakage at the cost of making the language worse in the long term - and we already have a way around this that we've used with other DIPS. So, let's please use a transitional compiler switch rather than introducing @implicit for copy constructors. @implicit is just going to make the language worse.

[aliak00]

All these produce deprecation errors now.

[RazvanN7]

Yes, I made the PR deprecating them, however a deprecation is not the same as rejecting code (error).

[quickfur]

Just copying from what I wrote in the forum:

• The DIP should address what @implicit means when applied to a function that isn't a ctor. Either it should be made illegal, or the spec should clearly state that it's ignored.

  • I prefer the former option, because that minimizes the risk of conflicts in the future if we were to expand the scope of @implicit to other language constructs.

  • However, the latter option is safer in that if existing user code uses @implicit with a different meaning, the first option would cause code breakage and require the user to replace all uses of @implicit with something else.

• The DIP needs to address what a copy ctor might mean in a situation with unions, and/or whether it's legal to use unions with copy ctors. There are a few important cases to consider (there may be others):

  • Should copy ctors even be allowed in unions?

  • The copy ctor is defined in the union itself.

  • The union contains fields that have copy ctors. If two overlapping fields have copy ctors, which ctor will get called? Should this case be allowed, or made illegal?

  • How would type qualifiers (const, immutable, etc.) interact with unions of the above two cases?

  • If a struct contains a union, and another non-union field that has a copy ctor, how should the compiler define the generated copy ctor of the outer struct?

• If a struct declares only one copy ctor, say mutable -> mutable, then according to the DIP (under the section "copy constructor call vs. standard copying (memcpy)"), declaring an immutable variable of that type will default to standard copying instead.

  • This means if the struct needs explicit handling of copying in a copy ctor, the user must remember to write all overloads of the copy ctor, otherwise there will be cases where standard copying is silently employed, bypassing any user-defined semantics that may be necessary for correct copying.

  • Shouldn't there be a way for the compiler to automatically generate this boilerplate code instead? Should there be a way to optionally generate warnings in such cases, so that the user can be aware in case default copying isn't desired?

• What should happen if the user declares a copy ctor as a template function? Should the compiler automatically use that template to generate const/immutable/etc. copy ctors when needed?

[thewilsonator]

This requirement makes it impossible to transition to this DIP, I suggest a transitional -dip10xx flag that, if set, will prefer to call a copy constructor over a postblit (probably along with a -vpostblit to make sure that you're doing what you think you are, especially w.r.t qualifier combinations). It will also make it easier to keep compatibility with older compilers, which is very important.

[aliak00]

How come it makes the transition impossible?

[aliak00]

Ah, it's because a struct "has" a postblit even if one of its members does and "it" actually does not ... then I see what you mean.

[thewilsonator]

More that that, unless the -dip10xxflag defines a version (or one defines their own to ease transition) you can't have the two defined which makes it much more difficult to switch between if, for some reason, your code breaks. It also means that you must version your code in order to compile with older compilers.

[thewilsonator]

because a struct "has" a postblit even if one of its members does and "it" actually does not

That doesn't help either.

[RazvanN7]

@quickfur

The DIP should address what @implicit means when applied to a function that isn't a ctor. Either it should be made illegal, or the spec should clearly state that it's ignored.

It is illegal. It is not clearly stated, but I thought it can be interpreted as such. I will add a mention.

The DIP needs to address what a copy ctor might mean in a situation with unions, and/or whether it's legal to use unions with copy ctors. There are a few important cases to consider (there may be others):

The copy constructor may be used in same places as a postblit => unions may not have copy constructors or fields with copy constructors.

If a struct declares only one copy ctor, say mutable -> mutable, then according to the DIP (under the section "copy constructor call vs. standard copying (memcpy)"), declaring an immutable variable of that type will default to standard copying instead.
This means if the struct needs explicit handling of copying in a copy ctor, the user must remember to write all overloads of the copy ctor, otherwise there will be cases where standard copying is silently employed, bypassing any user-defined semantics that may be necessary for correct copying.
Shouldn't there be a way for the compiler to automatically generate this boilerplate code instead? Should there be a way to optionally generate warnings in such cases, so that the user can be aware in case default copying isn't desired?

The philosophy is that copy constructors are declared whenever the user specifically wants to do something different than standard copying for a specific source-destination qualifier combination. This is a "pay on demand" strategy as you have to define different copy constructors as long as you are interested in doing things differently. If you want to treat mutable-mutable, immutable-immutable, const-const the same, you can just write an inout copy constructor. The disadvantage is that you should probably write shared inout one too.

What should happen if the user declares a copy ctor as a template function? Should the compiler automatically use that template to generate const/immutable/etc. copy ctors when needed?

The copy constructor cannot be templated. For now, you can use inout as a wild card. In the future, if copy constructors will be extended to do copies for types that are different (for example from int to S), then it will make more sense to accept templated copy constructors

[thewilsonator]

The copy constructor cannot be templated. I will update the DIP with this.

Even with a template this?

[RazvanN7]

Even with a template this?

Yes.

[aliak00]

Awesome stuff! :D

One thing that comes to mind which was not mentioned is a copy constructor with more than one parameter where all except for the first parameter have default arguments. I would think that should be allowed as a valid copy constructor as well, as it allows for one very handy idiom (the FILE, LINE, FUNCTION one).

[aliak00]

If it's only by ref then how does this work:

A rvalue() {
  return A();
}
A a = rvalue();

Would DIP 1016 be a prereq for this DIP?

[thewilsonator]

It would be moved, not copied, i think.

[RazvanN7]

Indeed, it is moved; it is stated a bit later that copy construction is performed only if the source is an lvalue.

[aliak00]

How come it makes the transition impossible?

[aliak00]

Ah, it's because a struct "has" a postblit even if one of its members does and "it" actually does not ... then I see what you mean.

[aliak00]

If it was not wanted then wouldn't the author make another a const ref or?

[aliak00]

Isn't this already called "blitting"?

[aliak00]

By implicitly convertible it means specifically the qualifiers of the type right? Because they have to be the same type anyway and I assume this doesn't have anything to do with alias this. In which case the phrasing here makes it seem like two different types are being taken in to consideration.

[RazvanN7]

By implicitly convertible it means specifically the qualifiers of the type right?

In the case of structs, yes, but for classes, implicit conversion is something different. These first 2 steps here were implemented in the compiler before copy constructors, so I choose this phrasing to show what copy constructors bring new into the scheme (which is the 3rd step).

In which case the phrasing here makes it seem like two different types are being taken in to consideration.

immutable T is different from T.

[aliak00]

Ah, I think I misunderstood the general idea here. Thanks for clarifying!

[aliak00]

This seems to conflict with (from section copy constructor call vs standard copying)

Whenever an initialization by copying is encountered, a call to a copy constructor is tried
and if a matching copy constructor is found it is used, otherwise if no copy constructor is
suitable, standard copying is employed

1. When the overload set does not match, then a standard copy is performed.
2. When the overload set does not match and alias this is present, alias this is performed
3. A copy constructor is considered to be more specialized

Today, if I have an alias this and no post blit, the alias this does not take precedence:

struct A {
    int a;
    immutable(A) fun() {
        writeln("Yo!");
        return immutable A(7);
    }

    alias fun this;
}

void main() {
    A a;
    A b = a; // No Yo!
}

[RazvanN7]

In your example the alias this is never attempted because there are no undefined lookups (A b = a is something the compiler knows how to do). However, here is a slightly modified version of your code:

struct A
{
    int[] a;
    immutable(A) fun()
    {
        writeln("Yo");
        return immutable A([7]);
    }

    alias fun this;
}

void main()
{
    A a;
    immutable A b = a;   // error: cannot implicitly convert expression a of type A to immutable(A)
}

If I'm not missing something this code should be forwarded to alias this, but it isn't, which IMO is a bug. The section about alias this was trying to state that in such situations copy construction takes precedence over alias this.

[thewilsonator]

(for future reference this bug was fixed).

[aliak00]

The alias this caveat from above throws a wrench in to this as well no? i.e. for those that do not, standard copying is employed, if possible, unless an alias this assignment is possible

[RazvanN7]

Indeed.

[aliak00]

s/would/"could possibly"

depends on the types in A (i.e. if it was a type with no indirections then we all good with a const ref).

Is this in the correct section? This is not a breaking change or a deprecation is it?

[RazvanN7]

If you take into account that the postblit does not offer the possibility of modifying the source, it can be seen as a breaking change. I'm sure that some folks might see it as a feature :D 🗡️

[aliak00]

But implicit copy construction was not even possible before so people will have to write new code to do this. Implicit copy construction that may modify the source will not occur ... erm ... "implicitly".

[aliak00]

I believe @jacob-carlborg has mentioned somewhere that you can avoid this? If that's possible then that'd be a big plus IMO.

[RazvanN7]

I honestly think that people should be discouraged to use UDAs that are also special keywords in the compiler.

[jacob-carlborg]

It's possible, that's how the @selector attribute is implemented. I don't see a reason making it a keyword.

[9il]

C++ has efficient for reference counting move constructor (it is a general purpose, but quite good for reference counting). Can we do the same with this DIP?

[thewilsonator]

It is still missing a transitional -dip10xx switch, but otherwise looks good.

[dgileadi]

Minor editorial nit: should probably read "...and the postblit will be used."

[radcapricorn]

The whole rationale behind shared postblits and/or copy constructors is based on assumptions that are, at least in my opinion, misguided. What, exactly, would be a purpose of a shared copy of a shared object? shared types, by definition, cannot, and shall not, be copyable. They're shared unique instances. A shared struct is either a global, or an allocated instance passed by reference. If you can freely make a copy, then sharing makes absolutely no sense.
The only contexts where it would make sense is acquiring an un-shared copy from a shared instance, or instantiating a shared instance from an un-shared one, both are beyond simple copying, they're type conversions, procedures which in the general case can only be reasoned about by user code.
Therefore, copy constructors/postblits for shared types are best made not allowed by the language wholesale, leaving any special treatment (i.e. conversion to/from shared) up to user code. This particular part of the DIP is trying to reason about a problem that is ill-treated (poorly specified) by the language, and ultimately would become a wasted effort.

[mdparker]

@RazvanN7 Hey! I'm going to do my customary editing pass over this on Wednesday or Thursday of this week in preparation for the Community Review. If you've got any outstanding changes to make, please try to get them done before then. Thanks!

[mdparker]

As soon as you've responded to my suggestions, I'll get this into Community Review. Thanks!

[mdparker]

the copy constructor -> copy constructor

[mdparker]

motivates -> demonstrates

[mdparker]

to fix -> to resolve

[mdparker]

was -> is

[mdparker]

this led to a series of problems -> a series of problems has arisen

[mdparker]

Of course, this -> This

[mdparker]

by means of casting : -> with a cast, e.g.

[mdparker]

the constructor -> existing constructors

might get -> might be

[mdparker]

This will print "Yo" subsequent to the implementation of this DIP, where before it printed nothing.

However, a case -> A case

[RazvanN7]

@mdparker Done. Thank you!

[Bolpat]

Do you want to allow additional optional parameters? Like this(ref typeof(this) x, bool deepCopy = false). C++ allows it. You might want to mention it, either in support or rejection.

[RazvanN7]

Yah. Thanks! To answer your question: default parameters will be supported.

[Bolpat]

Isn't the copy done at the returns? That way, fun does not need to copy a, it basically moves its local value, whereas gun has to copy the value to return it. The copy is them moved in the assignment b = gun(). NRVO is an optimization and not part of semantics.

[RazvanN7]

That is true, but the effect is as if the copy constructor would get called on the returned value. I wanted to avoid going into compiler specific generated code such as (A __tmp; __tmp.copyCtor(a); __tmp) for the return a line in the gun function.

[Bolpat]

Later you define implicitly generated copy constructor overloads. Do they have to be disabled manually or do you mean all explicitly written copy constructor overloads?

[RazvanN7]

I meant explicitly, in order to disable a generated copy constructor one must disable the copy constructor of the member. Anyway, after a chat with Walter we decided to give up on generating copy constructors in the way currently mentioned. I will update the DIP with the new strategy, soon.

[Bolpat]

Maybe use the wording: "... as if it was implemented using [the workaround above]". I think, this wording is too much, what the compiler should do and not what should happen.

[Bolpat]

There is something weird. Why should B b = bc; use alias this? The copy constructor can take bc perfectly. On the other hand, A a = ia; won't compile. The copy constructor cannot take an immutable value and A.fun cannot be used on an immutable value.

Also better rename the fields a of A and B to something different like n. It would make discussing the code easier.

[Bolpat]

Better use "Plain Old Data" as the header. Introduce the abbreviation in the next sentence.

[Bolpat]

Maybe use qual1 instead of $q1. This is not D syntax; introduce qual1 before using it. Like:
"Using qual_1 and qual_2 for any of the qualifiers that can be applied to the function and its parameter, ...". Names matter.

[Bolpat]

Dangling bracket here: [[postblit]

[Bolpat]

s/missing/mutable or "for copy constructors that create mutable values"

[Bolpat]

s/semantic/semantics (see here)