On Tuesday, 5 September 2017 at 14:43:19 UTC, John Colvin wrote:
> On Tuesday, 5 September 2017 at 12:41:45 UTC, Computermatronic wrote:
>> On Tuesday, 5 September 2017 at 12:20:14 UTC, crimaniak 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).
>
> https://issues.dlang.org/show_bug.cgi?id=17809

What kind of harm can this be? Can this be considered a feature?

On Tuesday, 5 September 2017 at 14:55:21 UTC, Void-995 wrote:

> Using unions? <Type>Count and <Type>Offset are different depending on input data, so the address where they are is varying depending on which file I've loaded. Or I didn't get what you meant.
 Yes, so you need separate union type for every type of input data. But these values are known in compile time, so you can do mixin, creating the union for each type like this:

union MyBinaryStructA
{
    ubyte[...] asBytes;
    struct asStruct
    {
        align(1):
        ubyte[...] dummy1; // padding before firstList
        MyBinarySubStructAForA[...] firstList;
        ubyte[...] dummy2; // padding between lists
        MyBinarySubStructBForA[...] secondList;
        ...
    }
}

unittest
{
    MyBinaryStructA a;

    a.asBytes = someBinarySourceForA; // fill from unstructured source

    auto item = a.asStruct.firstList[1]; // access to structure element
}

On Tuesday, 5 September 2017 at 21:18:11 UTC, crimaniak wrote:
> On Tuesday, 5 September 2017 at 14:55:21 UTC, Void-995 wrote:
>
>> Using unions? <Type>Count and <Type>Offset are different depending on input data, so the address where they are is varying depending on which file I've loaded. Or I didn't get what you meant.
>  Yes, so you need separate union type for every type of input data. But these values are known in compile time, so you can do mixin, creating the union for each type like this:
>
> union MyBinaryStructA
> {
>     ubyte[...] asBytes;
>     struct asStruct
>     {
>         align(1):
>         ubyte[...] dummy1; // padding before firstList
>         MyBinarySubStructAForA[...] firstList;
>         ubyte[...] dummy2; // padding between lists
>         MyBinarySubStructBForA[...] secondList;
>         ...
>     }
> }
>
> unittest
> {
>     MyBinaryStructA a;
>
>     a.asBytes = someBinarySourceForA; // fill from unstructured source
>
>     auto item = a.asStruct.firstList[1]; // access to structure element
> }

The whole thing is that I don't know either padding nor elements count. Those values are read from file. First you need to read whole file data and cast those bytes as pointer to file header structure. Offset of each list is bigger then size of the parent structure. Length of each list vary from 0 to whatever.

On Tuesday, 5 September 2017 at 22:51:45 UTC, Void-995 wrote:
> The whole thing is that I don't know either padding nor elements count. Those values are read from file. ...
Sorry, I was not attentive enough. Yes, you can't use unions in this case.

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.

Circumstances where some "context" is captured include:

 - template instantiations where an alias parameter requires a context in order to resolve the parameter correctly [[the instantiated function/struct/class will effectively become nested within whichever scope is determined to be needed in order to resolve the alias parameter -- whether the alias parameter is needed, used, or not]]

 - template instantiation of functions/structs/classes whose enclosing templates were declared within a function/struct/class [[the template instance's functions, structs, and classes will effectively become nested within the function/struct/class that the template was declared within -- whether the instantiated function/struct/class's original declaration strictly implied a need for an outer function/struct/class or not]]

 - and --hrmm... it's 6:20 AM; I haven't yet slept for the night; and I'm supposed to continue preparing to save myself from the strongest hurricane ever seen in the Atlantic Ocean in a couple hours, so I think that's where I'll end this partial list.

Some assorted details related to some miscellaneous capture situations:
 - https://dlang.org/spec/template.html#nested-templates
 - https://dlang.org/spec/template.html#nested_template_limitation
 - https://dlang.org/spec/template.html#aliasparameters
 - https://dlang.org/spec/template.html#limitations
 - https://dlang.org/spec/function.html#closures

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.