On Saturday, 14 July 2018 at 00:41:37 UTC, Andrei Alexandrescu
wrote:
The specification of @implicit is in the DIP in full: a
constructor that takes by reference a qualified typeof(this)
and has the @implicit attribute will be callable implicitly by
the compiler. There is no other meaning of @implicit. That
completes the spec of @implicit.
That is the problem: you are using a very generic name
("implicit") to signify both:
1) something very general ("will be callable implicitly by the
compiler") and
2) something very specific ("a constructor that takes by
reference a qualified typeof(this)")
If there is "no other meaning of @implicit" (other than the
intersection of those two properties) why don't you just call it
something like @copyctor?
On the other hand, if the name is chosen with the hope that the
meaning will be generalized in the future ("callable implicitly
by the compiler"), why don't you want to at least briefly discuss
that more general meaning?
What happens if you later conclude that a generic "callable
implicitly by the compiler" annotation has semantics that don't
quite align with those of this ctor annotation? Do you need to
introduce @implicitconv?
Surely we want the language constructs to be composable and
generalizable, and not just quirky one offs that you have to
memorize. This seems like a missed opportunity to make sure of
that.
