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

[Stefanos Baziotis]

On Wednesday, 11 September 2019 at 09:58:58 UTC, jmh530 wrote:
>
> 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.
>

For me, this DIP is the most complicated DIP I have seen - _just_ 
to handle
alias declarations / instatiations in function arguments.
And it already takes a lot of things for granted (i.e. the `Gen`
function in the DIP is not specified). I would not have been
able to complete it without some help from one of my professors.

What I mean is that this is not necessarily the easiest thing
to understand and even if it was, I'm not an expert in writing
formal specifications.

Regarding the implementation, well.. this a particularly draft
implementation. :P It is after 3 days of first opening DMD.

> 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) {
>
> }

I understand the reasoning, yes. I also think it would be very 
beneficial.
The problem is that throwing templates in general into the mix I 
think
will make the DIP way complicated. Also, I don't think I will be 
able
to derive a formal specification.

Btw, IMHO, templates are in general under-specified. Both in D 
and C++.
I might have missed something but to the best of my knowledge, 
they're
constrained to intuitive descriptions and examples. Especially 
considering
the C++'s `using`. And then it is left to the compiler implementor
to get to a specific behavior.

I tried this DIP to provide a formal specification for the 
subject. And I'm
here to answer questions and receive corrections as I understand 
this is
not necessarily the best formal specification ever.

- Stefanos