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

[Stefanos Baziotis]

On Wednesday, 11 September 2019 at 20:46:46 UTC, ag0aep6g wrote:
>
> 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.

I agree, changes have to be done though. Meaning, it should
not focus on alias declaration, it should be more general.

>
> 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.
>

It's not the syntactic part the problem, meaning parsing
and lexing. It's the rewriting capabilities of templates.
Check Description -> New (in bold) in the DIP.
_However_, it's obvious that these rewriting problems don't
apply only to alias declarations. Actually, they're borrowed
from templates. AFAIK, these rewriting capabilities are
not as formally described as they could, but it was not
the initial intention of this DIP to describe and it won't
be now.

What I mean is that it seems feasible to describe the resolution
pretty much the same way for both long-hand and short-hand.

>> 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.

Indeed, although now it might be possible. When I was 
experimenting with this,
the implementation seemed quite complicated indeed. So, I left it 
in a draft
stage where I hope will be a good starting point or at least give 
an idea.
(It actually solves the use cases that the people who wanted the 
feature
are interested. That includes the cases in any issue report I had 
seen).
Instead, I focused on describing the feature as completely as 
possible, which
should help both the implementation and the consistency of the 
feature.