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

[ag0aep6g]

On 11.09.19 20:29, Stefanos Baziotis wrote:
> So, the alternative:
> My first thought is being more high level.
> That is, currently the DIP is restricted to alias declarations,
> while we can have the same exact semantic entity using a
> different type of declaration. This has a lot of subtle details.
> Can these declarations have a common way of resolution ?

The longhand is a common way. If you base your DIP on the longhand only, 
then the shorthand follows automatically, because it's defined to do 
whatever the longhand does.

I.e., if your DIP says that this works:

     template A(T) { alias A = S!T; } /* longhand */
     struct S(T) { }
     void f(T)(A!T arg) { }
     void main() { f(S!int()); }

Then it follows from the existing spec that it also works when A is 
declared in shorthand style:

     alias A(T) = S!T; /* shorthand */

The shorthand is defined to be equivalent to the longhand, and the 
longhand works, so the shorthand also works. You don't even have to 
mention it in the DIP. It's already in the spec.

By the way, the same shorthand/longhand thing applies to function 
templates. The DIP currently only uses the shorthand, but it should also 
work with the longhand (and I'd just assume that it does as long as the 
DIP doesn't explicitly say otherwise).

> If yes, maybe this is too high-level and it results in yet
> another not-so-formal-but-intuitive description.
> If no, should we consider each case separately ? How many are they ?
> How complicated will the DIP be ?

I feel like working on the (concrete) syntax level is too low-level.

I think it's obvious that the new feature should be applied after lexing 
and parsing. You don't want to write your DIP in terms of characters or 
keywords.

To me, it also seems obvious that the new feature should be applied 
after shorthand and longhand syntaxes have been consolidated. I'd expect 
that the parser already does this, but I'm not sure.

Beyond that, I'm not knowledgeable enough to say when it should happen. 
If the shorthand/longhand consolidation is not done by the parser, and 
not in some very early semantics phase either, then that might make 
things complicated.

> And it's not clear whether I will have the time to do this.

That's perfectly understandable. No one (in their right mind) is going 
to blame you, if you don't manage to push this all the way.

It's a hard problem. The oldest Bugzilla issue for it is over a decade 
old, with a dozen or so duplicates. Fixing/implementing that kind of 
issue isn't usually a walk in the park, or someone would already have 
done it.