September 11Re: DIP 1023--Resolution of Template Alias Formal Parameters in Template Functions--Community Review Round 1
Posted in reply to ag0aep6g
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.
Copyright © 1999-2018 by the D Language Foundation