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
