Walter Bright:

> Pointing out these issues is exactly what @nogc is designed to do.

Using @nogc is like putting your code under a newly invented microscope, it allows to see things that I missed before :-)

Bye,
bearophile

On Thursday, 24 April 2014 at 13:35:39 UTC, bearophile wrote:
>     immutable int x = 3;
>     auto result = data[].map!(y => y * x);
> }
>
>
> test.d(1,6): Error: function D main @nogc function allocates a closure with the GC
>
> Such kind of code is common, so a good amount of range-based code can't be @nogc.

Why can't this be on the stack if the referenced local function (lambda) does not outlive the stack frame?

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

> On Thursday, 24 April 2014 at 13:35:39 UTC, bearophile wrote:
>>     immutable int x = 3;
>>     auto result = data[].map!(y => y * x);
>> }
>>
>>
>> test.d(1,6): Error: function D main @nogc function allocates a closure with the GC
>>
>> Such kind of code is common, so a good amount of range-based code can't be @nogc.
>
> Why can't this be on the stack if the referenced local function (lambda) does not outlive the stack frame?

It could. I don't think the compiler is smart enough, as it would need to verify result doesn't go anywhere (flow analysis).

I wonder if LDC/GDC could do it.

One interesting thing about this is that the compiler implementation may make some @nogc code valid on some compilers, and invalid on others, even though the resulting execution is the same.

-Steve

On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer wrote:
> One interesting thing about this is that the compiler implementation may make some @nogc code valid on some compilers, and invalid on others, even though the resulting execution is the same.

I don't think this is a desirable behavior. @nogc should be decided in the frontend, before closure allocation optimizations take place.

David

On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer wrote:
> It could. I don't think the compiler is smart enough, as it would need to verify result doesn't go anywhere (flow analysis).

In that case I'd like to see recursive inlining, if it makes stack allocations more probable.

On Friday, 25 April 2014 at 12:21:40 UTC, David Nadlinger wrote:
> On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer wrote:
>> One interesting thing about this is that the compiler implementation may make some @nogc code valid on some compilers, and invalid on others, even though the resulting execution is the same.
>
> I don't think this is a desirable behavior. @nogc should be decided in the frontend, before closure allocation optimizations take place.

Yes, but the language specification should guarantee that no heap allocation takes place at least for some simple cases. `scope` comes to mind... This can apply to other normally allocating operations, too, like `new` and array concatenation/appending.

On Fri, 25 Apr 2014 08:21:38 -0400, David Nadlinger <code@klickverbot.at> wrote:

> On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer wrote:
>> One interesting thing about this is that the compiler implementation may make some @nogc code valid on some compilers, and invalid on others, even though the resulting execution is the same.
>
> I don't think this is a desirable behavior. @nogc should be decided in the frontend, before closure allocation optimizations take place.

I don't know that it's desirable to have @nogc reject code even though an allocation does not occur. I agree the situation is not ideal, but @nogc is a practical optimization.

I can think of other cases where the GC may be optimized out. To reject such code in @nogc would make it much less attractive.

-Steve

On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer wrote:
> On Fri, 25 Apr 2014 08:21:38 -0400, David Nadlinger <code@klickverbot.at> wrote:
>
>> On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer wrote:
>>> One interesting thing about this is that the compiler implementation may make some @nogc code valid on some compilers, and invalid on others, even though the resulting execution is the same.
>>
>> I don't think this is a desirable behavior. @nogc should be decided in the frontend, before closure allocation optimizations take place.
>
> I don't know that it's desirable to have @nogc reject code even though an allocation does not occur. I agree the situation is not ideal, but @nogc is a practical optimization.
>
> I can think of other cases where the GC may be optimized out. To reject such code in @nogc would make it much less attractive.
>
> -Steve

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.

On Fri, 25 Apr 2014 09:20:08 -0400, Dicebot <public@dicebot.lv> wrote:

> On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer wrote:
>>
>> I don't know that it's desirable to have @nogc reject code even though an allocation does not occur. I agree the situation is not ideal, but @nogc is a practical optimization.
>>
>> I can think of other cases where the GC may be optimized out. To reject such code in @nogc would make it much less attractive.
>>
>
> 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.

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?

Consider that the fact that compiler X could have compiled a function that compiler Y is linking to, may actually be @nogc, because compiler X is better at avoiding GC calls. Wouldn't it make sense to be able to mark it @nogc and still use it from compiler Y?

-Steve

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.

Bye,
bearophile