On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu
wrote:
On 7/14/18 5:03 AM, Luís Marques wrote:
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?
I'm totally cool with giving the attribute a more obscure name
such as @copyctor or anything people want really.
(What follows is a personal opinion.
I think it's better to choose a more general attribute name
with reduced initial applicability. Then application of said
attribute can be extended to other functions with ease. In
contrast, an obscure attribute name is sure to be followed by
more obscure attribute names. And don't get me started about
inventing new syntax.
Regarding the hand-wringing over generality: we have an
exceedingly poor record of paralysis of analysis, whereby we'd
worry that every design decision potentially locks us out from
all other as-of-yet-unchosen design decisions. If history is
any indication, this sudden worry about vaguely-promising green
pastures of the future is a sign of malady. We want copy
construction. Conflating this with a very general schemata for
implicit conversion would not be a wise decision in my opinion.
I now deeply regret ever telling Razvan to mention future
possible directions. This DIP must do implicit copy
constructors and do it well, nothing less and nothing more.)
Andrei
I think in this case, a more obscure name like @copyctor is more
descriptive. I fear that at some point, a more general attribute
like "@implicit" will turn into the next "static". To me,
@implicit smells like one of those keywords that will grow to
carry many different meanings in different contexts and just end
up overly-broad.
-Jon
