On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On 07/11/2018 11:11 AM, Atila Neves wrote: > > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote: > >>> But there's a super explicit `@implicit` thing written right there... > >>> so should we expect that an *explicit* call to the copy constructor > >>> is not allowed? Or maybe it is allowed and `@implicit` is a lie? > >> > >> The @implicit is there to point out that you cannot call that method > >> explicitly; it gets called for you implicitly when you construct an > >> object > >> as a copy of another object. > > > > How is this different from other types of constructors or destructors? > > The main difference is that the compiler may insert calls to it implicitly. > > > 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.
Ohhh yeah, this. I finally understand your reasoning here! Okay, that is a meaningful use for @implicit, and I could get behind its introduction if it were extended to apply broadly to any constructor. If it's only used in this isolated case, and specifically disallowed in that useful broader case, it feels pointless, and probably a cause of frustration for people that expect that it should work broadly. The DIP mentions that it may be deployed broadly, but I'd like to see that resolved up-front. I could only decide to accept it in this case depending on that secondary decision.
