On Tuesday, 17 July 2018 at 04:04:33 UTC, Manu wrote:
On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, <
[email protected]> 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 ;)
Aye! And in this case it really is implicit copy construction.
With this attribute in the compiler I can also see a future DIP
that deprecates implicit construction and requires an explicit
@implicit be added to constructors! Which also sounds like a win
:D
It's not ideal that the implicit attribute does not have a larger
discussion around it. But it is nice to something in D where the
default is the conservative approach and the more liberal has to
be explicitly asked for.
And at the same time, at this point it really is an attribute
that is only applicable to copy constructors. So how much
expansion on that would be enough I wonder?
Cheers,
- Ali
