DIP 1023--Resolution of Template Alias Formal Parameters in Template Functions--Community Review Round 1
anonymous at example.com
Wed Sep 11 17:53:06 UTC 2019
On 11.09.19 17:48, Stefanos Baziotis wrote:
> On Wednesday, 11 September 2019 at 14:14:31 UTC, ag0aep6g wrote:
>> So unless your DIP states that it changes the meaning of the alias
>> template shorthand syntax, we expect that it also works with the
> It does as far as I'm concerned. It always states alias
> declarations  and template alias instantiations
> with regard to alias declarations.
> The "longhand" version is not an alias declaration, it
> is a template declaration.
So you intend to introduce a difference between shorthand and longhand
That's awful. To me, that would be a reason to reject the DIP.
> Firstly, there are things to consider regarding the handling
> inside the compiler. Although that has to do with
> the implementation, which I don't think we should focus on.
> The thing is, semantics is about what something means.
> But, regarding formal specifications, there's another
> important topic. Actually, the most important for this DIP,
> which is how something is resolved to be a specific semantic
> The "longhand" and "shorthand" versions are semantically the same,
> i.e. they correspond to the same semantic entity, but the way
> one arrives to this entity is different. Meaning, the rules
> And one should consider that. Otherwise, the burden
> is left to the compiler implementor.
If I understand correctly, you're saying that you want to consider ease
of implementation in the compiler.
That's fine. But:
1) It's not obvious that you're actually simplifying the implementation
by restricting the feature to the shorthand syntax. Your prototype
implementation seems to work just fine with the longhand syntax.
2) Even if it happens to be easier to implement, you have to weigh that
against adding a surprising special case to the language. I don't think
it's going to be a net positive.
More information about the Digitalmars-d