[Issue 18058] @nogc and forwarding lazy argument, particularly with scope

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=18058

--- Comment #6 from Maksim Fomin <mxfm at protonmail.com> ---
(In reply to Shachar Shemesh from comment #4)
> (In reply to Seb from comment #2)
> > FWIW that attributes are set wrongly on lazy parameters and their function
> > is a well-known bug and has been around for a long time.
> 
> True, but it wouldn't be a problem had the overly complex forwarding not
> take place.
> > 
> > For yours:
> > 
> > ---
> > import object;
> > @nogc void func1(lazy scope string msg)
> > {
> > }
> > void func2(lazy scope string msg)
> > {
> > 	func1(delegate string() => msg()); // <- lambda doesn't have @nogc
> > }
> > ---
> 
> The problem is not that the lambda doesn't have @nogc. The problem is that
> if we're going to provide a lambda there, it has no choice *but* to GC. The
> lambda has to have access to the frame (because "scope" was not honored),
> and so must allocate.

Exactly. This is how D works: some feature is lowered to code and if lowered
code does not work, than the original code must be rewritten. Yes, compiler
errs strangely as was mentioned in the forum. I am not aware of any example
(except UFCS which is different case) where compiler is smart enough to know in
advance than lowered code will not work, but compiler tries to rewrite in other
way because it can work (i would call such behavior 'semantic optimization'). 

> The issue here is that, once you've started lowering, the code the compiler
> emits is way under-optimized. It essentially creates a lambda whose sole
> purpose is evaluating another delegate that has the precise same interface.
> Had that redundant delegate not been generated, there would not be a need to
> allocate func2's frame with a GC, even without scope on the lazy.

As mentioned previously, this is how D works. Optimization refers to code
optimization and this stage happens after semantic analysis.

--