On Saturday, 22 September 2018 at 17:43:57 UTC, 12345swordy wrote:
> If that where the case, then why not make it an actual keyword? A frequent complaint regarding D is that there are too many attributes, this will undoubtedly adding more to it.

When I (and surely others like me) complain that there are too many attributes, the complaint has nothing to do with the @ character. I consider "nothrow" and "pure" to be part of the problem and they lack @.

On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe via Digitalmars-d-announce wrote:
> On Saturday, 22 September 2018 at 17:43:57 UTC, 12345swordy wrote:
> > If that where the case, then why not make it an actual keyword? A frequent complaint regarding D is that there are too many attributes, this will undoubtedly adding more to it.
>
> When I (and surely others like me) complain that there are too many attributes, the complaint has nothing to do with the @ character. I consider "nothrow" and "pure" to be part of the problem and they lack @.

Yeah, the problem has to do with how much you have to mark up your code. Whether you have @foo @bar @baz or foo bar baz is pretty irrelevant. And keywords eat up identifiers, so they're actually worse.

In addition, most of the complaints about @implicit have to do with the fact that it doesn't even add anything. It's annoying that we have @nogc, @safe, pure, etc. but at least each of those adds something. @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist.

- Jonathan M Davis

On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis wrote:
> On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe via Digitalmars-d-announce wrote:
>> [...]
>
> Yeah, the problem has to do with how much you have to mark up your code. Whether you have @foo @bar @baz or foo bar baz is pretty irrelevant. And keywords eat up identifiers, so they're actually worse.
>
> In addition, most of the complaints about @implicit have to do with the fact that it doesn't even add anything. It's annoying that we have @nogc, @safe, pure, etc. but at least each of those adds something. @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist.
>
> - Jonathan M Davis

It appears that @implicit has been removed from the implementation [1], but not yet from the DIP.

https://github.com/dlang/dmd/commit/cdd8100

On Saturday, September 22, 2018 8:40:15 PM MDT Nicholas Wilson via Digitalmars-d-announce wrote:
> On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe
> >
> > via Digitalmars-d-announce wrote:
> >> [...]
> >
> > Yeah, the problem has to do with how much you have to mark up your code. Whether you have @foo @bar @baz or foo bar baz is pretty irrelevant. And keywords eat up identifiers, so they're actually worse.
> >
> > In addition, most of the complaints about @implicit have to do with the fact that it doesn't even add anything. It's annoying that we have @nogc, @safe, pure, etc. but at least each of those adds something. @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist.
> >
> > - Jonathan M Davis
>
> It appears that @implicit has been removed from the implementation [1], but not yet from the DIP.
>
> https://github.com/dlang/dmd/commit/cdd8100

Well, that's a good sign.

- Jonathan M Davis

On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson wrote:
> It appears that @implicit has been removed from the implementation [1], but not yet from the DIP.
>
> https://github.com/dlang/dmd/commit/cdd8100

Good, It's not needed.

On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis wrote:
> @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist.
>
> - Jonathan M Davis

I somewhat agree with this argument, but overall I hate this attitude of "we should just make the change because it *probably* won't break any code", and then bonus points for "code that does this is wrong anyway so we shouldn't care if we break it". I've already been burned by that a couple times using D, and I imagine heavy corporate users with large code bases have many more problems with this.

On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson wrote:
> > It appears that @implicit has been removed from the implementation [1], but not yet from the DIP.
> >
> > https://github.com/dlang/dmd/commit/cdd8100
>
> Good, It's not needed.

@implicit is desperately needed (just not for copy constructors!). Do you have confidence that an @implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support @implicit's introduction.

On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
> On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>
>> On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson wrote:
>> > It appears that @implicit has been removed from the implementation [1], but not yet from the DIP.
>> >
>> > https://github.com/dlang/dmd/commit/cdd8100
>>
>> Good, It's not needed.
>
> @implicit is desperately needed (just not for copy constructors!). Do you have confidence that an @implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support @implicit's introduction.

If we are going to introduce the keyword/attribute implicit then it needs its own DIP. As of now, this DIP have a very weak justification for it.

-Alex

On Mon, 24 Sep 2018 at 12:40, 12345swordy via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
> > On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> >>
> >> On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson wrote:
> >> > It appears that @implicit has been removed from the implementation [1], but not yet from the DIP.
> >> >
> >> > https://github.com/dlang/dmd/commit/cdd8100
> >>
> >> Good, It's not needed.
> >
> > @implicit is desperately needed (just not for copy constructors!). Do you have confidence that an @implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support @implicit's introduction.
>
> If we are going to introduce the keyword/attribute implicit then it needs its own DIP. As of now, this DIP have a very weak justification for it.

I certainly agree; I'm fairly sure I produced the very first critical
comment on this issue when it first landed, which went like "@implicit
is a dependency and needs a dependent dip", which Andrei brushed off.
I still believe it's a separate feature, and it's a dependency for
this particular DIP, so that should come first... but here's the
thing; that's just not how dlang works around here.
We like the idea that there's process and structure, but there's not,
and you just need to be practical about maneuvering towards the goals
you want in the ways that manifest.

In this case, having @implicit is a very real and desirable goal, it's
been a sore hole in the language since ever... so anything that moves
it towards reality is preferable to nothing.
While I felt strongly about my conviction initially (that there should
be a dependent DIP), I realised that a much more useful and practical
position was to allow this dip to introduce @implicit implicitly
(heh)... that's a much better reality than waiting an addition year or
2 (if ever!) for the thing otherwise.

I encourage people to consider this holistically and consider the practicality of allowing it, even thought it's not a strictly principled in terms of process ;)

copy-ctor is good, @implicit is also good... we want both. Even though copy-ctor is not strictly dependent on @implicit, allowing it will satisfy that there's not a breaking change, it it will also self-justify expansion of @implicit as intended without a separate and time-consuming fight, which is actually the true value of this DIP!

On Monday, September 24, 2018 10:44:01 AM MDT Meta via Digitalmars-d- announce wrote:
> On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis
>
> wrote:
> > @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist.
> >
> > - Jonathan M Davis
>
> I somewhat agree with this argument, but overall I hate this attitude of "we should just make the change because it *probably* won't break any code", and then bonus points for "code that does this is wrong anyway so we shouldn't care if we break it". I've already been burned by that a couple times using D, and I imagine heavy corporate users with large code bases have many more problems with this.

In this particular case, a transitional compiler flag like we've done with other DIPs makes _far_ more sense than forcing everyone to use an attribute forever - especially when forgetting to use the attribute is going to be a further source of bugs, one which would _easily_ outweigh any code breakage caused by not having the attribute. But having a transitional compiler flag would give us a way to deal with the potential code breakage if it exists.

- Jonathan M Davis