DIP 1023--Resolution of Template Alias Formal Parameters in Template Functions--Community Review Round 1

[jmh530]

On Wednesday, 11 September 2019 at 02:02:58 UTC, Stefanos 
Baziotis wrote:
> [snip]
>
> Nonetheless, thank you very much for pointing it out! Either 
> it's part of this
> DIP or not.
>
> - Stefanos

No problem. ag0aep6g's comments above are also pretty spot on.

I'm not a compiler expert or anything, so I didn't go through 
every little piece of the DIP initially in order to try to grok 
how it worked. I don't have a good sense of how the compiler 
currently resolves templates, so trying to understand how it 
worked in this specific case seemed like a big hill to climb.

The reason why I was talking about the explicit template syntax 
is because it provides a lot of flexibility.

When talking about Atila's concepts library above, the thing that 
is in the back of my mind is something like isInputRange (he 
provides an example in the Readme.md). One issue with passing an 
input range to a lot of phobos functions is that if you pass 
something that isn't an input range the error message isn't 
specific about why it isn't an input range. For instance, did you 
forget to define popFront? The concepts library helps provide 
better error messages in this case. However, it currently 
requires you to use @models at the top of the struct in order to 
check this information. This requires the user to put models UDA 
before their own struct, rather than this happening at the point 
of the function. If we were able to do something like below, then 
the user does not need to put it on their own structs. I think 
that would make the concepts library much more powerful.

template InputRange(T) {
     import concepts: models, isInputRange;
     static assert(models!(Foo, isInputRange));
     alias InputRange = T;
}

void useInputRange(T)(InputRange!T foo) {

}