On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
>> It is unacceptable to have code that fails with one compiler and works with the other despite the shared frontend version. Such "enhanced" @nogc attributes must be placed into compiler-specific attribute space and not as a core language feature.
>
> Like I said, this may be the ideologically correct position, but please explain to the poor user that even though the compiler does not invoke the GC in his function, it still cannot be @nogc.
>
> I think in this case, @nogc is not a good name.

Which is the very reason why I was so insisting of defining exact set of cases when optimisation is to be guaranteed in spec (before releasing @nogc). Unfortunately, with no success.

> But what really is the difference between a function that is marked as @nogc that compiles on compiler X but not compiler Y, and some custom attribute that compiles on X but not Y?

There are no user-defined attributes that can possibly fail on only some compiler. And compiler-specific attributes are part of that compiler documentation and never part of language spec. This is the difference.

On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot <public@dicebot.lv> wrote:

> On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
>>> It is unacceptable to have code that fails with one compiler and works with the other despite the shared frontend version. Such "enhanced" @nogc attributes must be placed into compiler-specific attribute space and not as a core language feature.
>>
>> Like I said, this may be the ideologically correct position, but please explain to the poor user that even though the compiler does not invoke the GC in his function, it still cannot be @nogc.
>>
>> I think in this case, @nogc is not a good name.
>
> Which is the very reason why I was so insisting of defining exact set of cases when optimisation is to be guaranteed in spec (before releasing @nogc). Unfortunately, with no success.

Well, @nogc is not released yet. Please tell me we don't have to avoid breaking code based on git HEAD...

>
>> But what really is the difference between a function that is marked as @nogc that compiles on compiler X but not compiler Y, and some custom attribute that compiles on X but not Y?
>
> There are no user-defined attributes that can possibly fail on only some compiler. And compiler-specific attributes are part of that compiler documentation and never part of language spec. This is the difference.

But such a situation would not violate a spec that says "@nogc means there are no hidden GC calls." And the end result is identical -- I must compile function foo on compiler X only.

I agree there are likely no precedents for this.

Another option would be to put such a compiler-specific attribute around the code in question rather than a different attribute than @nogc on the function itself. I think there's really no avoiding that this will happen some way or another.

-Steve

On Fri, 25 Apr 2014 11:29:37 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot <public@dicebot.lv> wrote:
>
>> On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
>>> But what really is the difference between a function that is marked as @nogc that compiles on compiler X but not compiler Y, and some custom attribute that compiles on X but not Y?
>>
>> There are no user-defined attributes that can possibly fail on only some compiler. And compiler-specific attributes are part of that compiler documentation and never part of language spec. This is the difference.
>
> But such a situation would not violate a spec that says "@nogc means there are no hidden GC calls." And the end result is identical -- I must compile function foo on compiler X only.

You know what, in fact, @nogc may need to be re-branded as compiler-specific.

-Steve

On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer wrote:
> On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot <public@dicebot.lv>
>> Which is the very reason why I was so insisting of defining exact set of cases when optimisation is to be guaranteed in spec (before releasing @nogc). Unfortunately, with no success.
>
> Well, @nogc is not released yet. Please tell me we don't have to avoid breaking code based on git HEAD...

It has become a blocker for next release though. It has been repeated numerous times that such features need to be developed in own feature branches until design is considered at least somewhat solid =/

>>
>>> But what really is the difference between a function that is marked as @nogc that compiles on compiler X but not compiler Y, and some custom attribute that compiles on X but not Y?
>>
>> There are no user-defined attributes that can possibly fail on only some compiler. And compiler-specific attributes are part of that compiler documentation and never part of language spec. This is the difference.
>
> But such a situation would not violate a spec that says "@nogc means there are no hidden GC calls." And the end result is identical -- I must compile function foo on compiler X only.

It is invalid and useless spec on its own. It would have been a valid spec if it also had a chapter with definitive list of all cases when hidden GC calls can happen and when are guaranteed to be optimized away. Otherwise such spec is as useful as one that says "Maybe your code will compile".

> I agree there are likely no precedents for this.
>
> Another option would be to put such a compiler-specific attribute around the code in question rather than a different attribute than @nogc on the function itself. I think there's really no avoiding that this will happen some way or another.

I think there should be both. Saying that you need to marry specific compiler forever once you want to use @nogc is pretty much same as saying "don't use @nogc".

On Friday, 25 April 2014 at 15:32:40 UTC, Steven Schveighoffer wrote:
>
> You know what, in fact, @nogc may need to be re-branded as compiler-specific.

You should have a compiler switch that let's you get "compiler-optimal non-portable @nogc".

On Fri, 25 Apr 2014 20:50:46 -0400, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Friday, 25 April 2014 at 15:32:40 UTC, Steven Schveighoffer wrote:
>>
>> You know what, in fact, @nogc may need to be re-branded as compiler-specific.
>
> You should have a compiler switch that let's you get "compiler-optimal non-portable @nogc".

I feel like I'm being a nag, but it sure seems to me like having something like that is no different than custom behavior of @nogc. Basically, I have a file blah.d, which can only be compiled with X, even if it's only with the option X -extraNogcFunctionality

In other words, I have this function. It can avoid GC allocations if the compiler can do extra steps to prove it. But not all compilers go to these lengths.

So if I only care about compiling with savvy enough compilers, why do I need to use some special compiler-specific escape? I think the attribute is fine being defined as "if you can't do this without calling the GC, refuse to compile," and the compiler may or may not compile it.

In any case, I don't need another explanation, I don't think it will ever make sense to me.

-Steve

On Saturday, 26 April 2014 at 04:49:07 UTC, Steven Schveighoffer wrote:
> In any case, I don't need another explanation, I don't think it will ever make sense to me.

It makes sense because there are two different use cases:

1. Library authors who need a more conservative interpretation of @nogc.

2. Binary release productions who only want to be certain that the GC is not called where it could lead to a crash.


It would be annoying to have to rewrite code when the compiler actually knows that it does not touch the GC. So the latter use cases need the less conservative approach.

On 4/25/2014 7:28 AM, bearophile wrote:
> Dicebot:
>
>> It is unacceptable to have code that fails with one compiler and works with
>> the other despite the shared frontend version. Such "enhanced" @nogc
>> attributes must be placed into compiler-specific attribute space and not as a
>> core language feature.
>
> This problem was underlined during this thread far before the merging of the
> @nogc implementation. Why have Walter & Andrei ignored the problem? What's the
> point of creating a DIP if you ignore the problems found in its discussion?
> What's the point of 338 comment posts if Walter goes on anyway with the original
> idea? There are some problems in the D development method that must be addressed.

The @nogc logic is entirely contained in the front end, and is not affected by back end logic.

On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer wrote:

> Well, @nogc is not released yet. Please tell me we don't have to avoid breaking code based on git HEAD...

We've already done that before, with UDA's. So, you never know.

--
/Jacob Carlborg

On 2014-04-25 16:28, bearophile wrote:

> This problem was underlined during this thread far before the merging of
> the @nogc implementation. Why have Walter & Andrei ignored the problem?
> What's the point of creating a DIP if you ignore the problems found in
> its discussion? What's the point of 338 comment posts if Walter goes on
> anyway with the original idea? There are some problems in the D
> development method that must be addressed.

That's a problem. The problem is if someone has an idea/code it wants to be merged, it's enough to convince one developer with push right to get it merged.

-- 
/Jacob Carlborg