Copy Constructor DIP and implementation

[H. S. Teoh]

On Tue, Sep 11, 2018 at 03:08:33PM +0000, RazvanN via Digitalmars-d-announce wrote:
> I have finished writing the last details of the copy constructor
> DIP[1] and also I have published the first implementation [2].
[...]

Here are some comments:

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


T

-- 
Change is inevitable, except from a vending machine.