On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
> 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. > But that's the point, and the key advantage of the name ;)