DMD and GDC are unnecessarily using heap allocations for closures

[Siarhei Siamashka]

On Monday, 30 May 2022 at 10:41:10 UTC, Johan wrote:
> The `@nogc` attribute is a language-level guarantee that no GC 
> allocations will happen in that function.

Then maybe another attribute 
@makebestefforttohavenocginoptimizedbuild (with a different 
shorter name) could be introduced? So that the GC allocations 
originating from such functions would be additionally marked as 
'please optimize me out' by the frontend. The GC2Stack IR 
optimization pass would do its normal job. And if some of such 
marked GC allocations still remain after GC2Stack, then the 
compiler could spit out a helpful performance warning message. 
The non-optimized debug builds can do GC allocations without 
making any noise. And its okay for any compiler to just ignore 
this attribute (similar to how 'inline' is handled in C language).

I think that there are two somewhat different use cases for @nogc:
1. we can't tolerate any GC allocations, because the runtime has 
no garbage collector at all
2. we can do GC allocations, but strongly desire to avoid them 
for performance reasons

The current @nogc is apparently designed for the use case 1 and 
is overly conservative. But I'm primarily interested in the use 
case 2.

> This guarantee can not depend on an optimization, unless any 
> compiler implementation is required to implement that 
> optimization also for unoptimized code: effectively making it 
> no longer an "optimization", but just normal language behavior. 
> (example: C++17 requires copy elision when a function returns a 
> temporary object+ (unnamed object), but does not require it 
> when a function returns a named object.)

Would it be difficult/practical to implement that optimization 
(or some simplified form of it) also for unoptimized code in the 
frontend and make it the normal language behavior?