Parameterized delegate attributes

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Sep 29 10:22:45 PDT 2016


On 9/28/16 5:35 PM, Lodovico Giaretta wrote:
> On Wednesday, 28 September 2016 at 20:23:10 UTC, pineapple wrote:
>> But using a templated opApply currently breaks type inference in
>> `foreach`, right?
>>
>> It'd be really nice if that were fixed.
>
> Yeah, it would be nice, but I don't think it's technically possible to
> fix it. The compiler cannot "guess" the correct opApply instantiation if
> you don't specify the variable type.

opApply suffers from a few problems. IMO, it should almost always be 
inlined, so the compiler can "cheat" with attribute inference.

It's an interesting idea to apply inferred attributes to a function 
based on the given delegate, especially for pure and @nogc. As I 
understand it, those attributes don't modify generated code at all, they 
just restrict what you can call (and in the case of strong pure, allow 
call-site optimizations). If everything you call aside from the delegate 
is pure and @nogc, then the attributes can be inferred at the call site 
to be whatever the delegate is, and no separate template generation 
needs to happen.

nothrow, I think, modifies how the code is generated. But it's possible 
we could do the same here in a way that allows nothrow to be inferred at 
call site, but generate the stack unwinding code just in case (so only 
one function is ultimately emitted).

Note, we may not need to actually add any syntax for this. If you return 
auto from opApply, you guarantee the code is available, so the compiler 
can do the inference.

-Steve


More information about the Digitalmars-d mailing list