Templates, D way
Corey Lubin via Digitalmars-d
digitalmars-d at puremagic.com
Fri Sep 8 04:49:23 PDT 2017
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.
More information about the Digitalmars-d
mailing list