On 07/12/2018 10:54 AM, Jonathan M Davis wrote:
On Thursday, 12 July 2018 07:45:30 MDT Andrei Alexandrescu via Digitalmars-d
wrote:
I also very much dislike the syntax - it makes no sense to me at all. I
commented on the PR itself asking why it differs so much from C++ -
specifically, what's bad about the C++ way of doing things there that we
want to avoid?
C++ is at the other end of the spectrum - constructors are too implicit,
so the "explicit" keyword has been introduced with the advice to use it
in the vast majority of cases. If C++ could do it again, it would make
everything explicit and add an "implicit" keyword.
That's only an issue in C++, because C++ uses constructors for implicit
conversions unless you mark them with explicit. D doesn't ever do implicit
conversions like that. All constructors are effectively explicit. Is this
DIP proposing that we add such implicit conversions?
The DIP is proposing what's in the DIP :o). We actually clarify this in
text:
"The type of the parameter to the copy constructor needs to be identical
to typeof(this); an error is issued otherwise. This requirement may be
relaxed in the future in order to accomodate implicit copying from
objects of a different type:" [example follows]
I really don't understand what the purpose of @implicit is here. What's the
problem of just going off of the type of the constructor's single parameter
to determine whether it's a copy constructor?
That would silently change semantics of existing code, which is to be
avoided.
Andrei
