On Tuesday, 17 July 2018 at 04:04:33 UTC, Manu wrote:
> 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 ;)

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

On Saturday, 14 July 2018 at 00:57:14 UTC, Andrei Alexandrescu wrote:
> [...]
> chucklesomely profligate and ridiculously baroque.
>
>
> Andrei

Hahaha this sentence... amazing!  :D

I was going to propose auto this(ref A other) {} but nevermind :p

Cheers,
- Ali

On 07/17/2018 03:03 PM, aliak00 wrote:
> Can you explain a bit more here? How does having implicit as a compiler recognized UDA avoid breaking changes as opposed to it being implemented like @nogc/@safe (how are those implemented differently anyway?)

In a UDA `@implicit`, `implicit` is just a normal symbol. So the normal lookup rules apply. In particular, you can shadow an imported `implicit` with a local one:

    --- object.d
    enum implicit = 1; /* Actual implementation would be different. */

    --- bar.d
    /* invisible default `import object` here */
    @implicit void f() {}
    static assert(__traits(getAttributes, f)[0] == 1);
        /* Passes. `object.implicit` is used. */

    --- baz.d
    /* invisible default `import object` here */
    enum implicit = 2;
    @implicit void f() {}
    static assert(__traits(getAttributes, f)[0] == 2);
        /* Passes. The local `implicit` is used. */

You can't do that with `@safe`, because `@safe` is not a UDA, and `safe` is not a symbol there. `@safe` is special syntax, recognized as a whole by the parser. No symbol lookup is happening.

You can see the difference if you change all occurrences of "implicit" to "safe" in that code. Won't work.

As for breakage, baz.d is working code today. With `@implicit` as a UDA, it keeps working in the same way. With `@implicit` as a new non-UDA attribute, it will change its meaning, and the assert will fail.

On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote:
> 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.)

I also think a more general attribute is better. I think there's a middle ground between total analysis paralysis and no discussion of concept generality. I had hoped some thought would be given to the implications of implicit but overall I'm still happy, and I trust your judgement. BTW, I would still have brought it up even if the DIP didn't mention future directions :-)

On Tuesday, 17 July 2018 at 14:41:06 UTC, ag0aep6g wrote:
> On 07/17/2018 03:03 PM, aliak00 wrote:
>> [...]
>
> In a UDA `@implicit`, `implicit` is just a normal symbol. So the normal lookup rules apply. In particular, you can shadow an imported `implicit` with a local one:
>
> [...]

Ah, gotcha! Thank you!

On Friday, 13 July 2018 at 12:31:41 UTC, Atila Neves wrote:
> On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote:
>> On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 7/12/18 6:34 PM, Manu wrote:
>>> > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> >>
>> [..]
>> doesn't perform copy construction?
>>   1. the function is highly unlikely to exist because postblit; it's a
>> meaningless function to write. are there any known instances of that
>> signature in the wild?
>
> https://github.com/search?q=%22this%5C%28ref%22+language%3AD&type=Code
>
> The answer seems to be: not many. Most of the results above are false positives because github won't let me escape the left parenthesis.
>
> Atila

https://www.google.no/search?q=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad&oq=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad

On Tue, 17 Jul 2018 at 10:20, aliak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Friday, 13 July 2018 at 12:31:41 UTC, Atila Neves wrote:
> > On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote:
> >> On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>>
> >>> On 7/12/18 6:34 PM, Manu wrote:
> >>> > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>> >>
> >> [..]
> >> doesn't perform copy construction?
> >>   1. the function is highly unlikely to exist because
> >> postblit; it's a
> >> meaningless function to write. are there any known instances
> >> of that
> >> signature in the wild?
> >
> > https://github.com/search?q=%22this%5C%28ref%22+language%3AD&type=Code
> >
> > The answer seems to be: not many. Most of the results above are false positives because github won't let me escape the left parenthesis.
> >
> > Atila
>
> https://www.google.no/search?q=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad&oq=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad

I clicked through quite a few. Every function that's a valid copy
constructor by the definition here does indeed perform a valid copy
construction with no side-effects, as predicted. Existing functions
interpreted as copy constructors under this DIP would continue to work
as intended.
There's a ridiculously low probability that any such wild function
that would be broken by a no-attribute version of this DIP exists.