On Friday, 8 September 2017 at 10:27:57 UTC, Corey Lubin wrote:
On Tuesday, 5 September 2017 at 12:41:45 UTC, Computermatronic
wrote:
I find it very strange that this works, as a non-mixin
template should not be able to capture the context of where it
was instantiated. If you take the alias template parameters
out it behaves how it should (that is an error message saying
this is not accessible).
Computermatronic (and crimaniak and John Colvin):
The behavior is as should be expected and is part of the
definition of how templates' alias parameters are supposed to
work.
The error that occurs when you stop using an alias parameter
occurs because you're no longer forcing the capture of an
enclosing scope by passing in an alias parameter that requires
such a scope; not because the error should have occurred the
first time as well.
I just actually payed attention to what the example code does
just now. Looking at the specific example, I suppose I can see
what the "strangeness" that's being referred to is. I suppose
that even though the context is indeed captured in whole:
1) the fact that the template's original declaration presents
like an ordinary freestanding function makes it look weird (like
a mixin template function might look weird referring to a context
it's not in yet, except more weird because the hinting mixin
keyword indicating it could be mixed in anywhere isn't there)
2) the expectation is that the sneakily stolen context will/can
only be used for and via the alias parameters it was created
captured for, and that the allowing of explicit `this` usage
within the definition is too much of a compiler implementation
leak?
With regards to #2, it is true, of course.
(though it makes it easier for implementations)
Gotta run.
