Templates, D way

[Corey Lubin via Digitalmars-d]

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.