On Friday, 21 May 2021 at 00:31:52 UTC, TheGag96 wrote:

Once it is all inlined, the backend ought to be able to see what is going on here and elide the allocations.

@nogc might not pass that though since it is before all those optimizations are performed......

But like i just checked ldc -O and it indeed optimizes it out today.

On Friday, 21 May 2021 at 00:54:27 UTC, Max Haughton wrote:

int i = 3;
someRange.map!(x => x.thing == i).each!writeln;

I was a little surprised that it needs the GC in the first place. It's a template parameter after all. Here, it even seems a runtime delegate parameter would shine since it could be marked scope. If nothing else goes on, an allocation is not necessary. It's even @nogc. (Maybe the lambda bound to the alias could have scope implied?)

On Friday, 28 May 2021 at 02:41:27 UTC, Q. Schroll wrote:

It isn't the lambda that allocates per se, it is the MapResult struct that cannot necessarily be scope since it doesn't know if the range will be stored or returned or whatever.

Though perhaps if the returned map result inherited the lifetime of the captured variables it could work, just that gets complicated.

On Friday, 28 May 2021 at 02:47:41 UTC, Adam D. Ruppe wrote:

I suspect the compiler should be able to see through it after a few rounds of inlining.

If there are so many layers that it doesn't, I suspect one allocation isn't going to be your bottleneck.

On Friday, 28 May 2021 at 13:47:32 UTC, deadalnix wrote:

ldc -O is able to elide the allocation: https://d.godbolt.org/z/9aoMo9hbe

However, the code still does not qualify as @nogc, because @nogc analysis is done prior to optimization.

On Friday, 28 May 2021 at 14:29:50 UTC, Paul Backus wrote:

Some more context (i.e. how LDC goes about doing this)

https://d.godbolt.org/z/jsPdoTxY1

https://github.com/ldc-developers/ldc/blob/master/gen/passes/GarbageCollect2Stack.cpp

GCC does not do this optimization (yet?), but it does for malloc and new in C++.

On Friday, 28 May 2021 at 14:29:50 UTC, Paul Backus wrote:

I've long argued that nogc needs to trigger n leaks, not allocations, and this is one more example as to why.

And tracking leak isn't as crazy as it sound whn you track ownership, a leak is a transfers of ownership to the GC.

On Sunday, 30 May 2021 at 21:09:36 UTC, deadalnix wrote:

I don't disagree that tracking ownership through the type system is desirable, but it isn't possible without explicit ownership. Shape analysis get tricky very fast.

On Monday, 31 May 2021 at 15:08:34 UTC, Ola Fosheim Grøstad wrote:

I think it is unavoidable. DIP1000 and alike are just doing exactly that while pretending they aren't, and it is causing a parsing XML with regex kind of running problem - it looks like it'll actually work, but it doesn't.

On Monday, 31 May 2021 at 23:37:21 UTC, deadalnix wrote:

True, no point in avoiding the machinery if that is what one is aiming for. Better to take the full machinery with explicit annotations, and then provide syntactical sugar for the common case if that is desirable. Going the other way will most likely be messy.