Parameters declared as the alias of a template won't accept the arguments of the same type.

[Mike Parker]

On Monday, 2 May 2022 at 00:54:40 UTC, Elfstone wrote:

> Thanks. This breaks a lot of things. I don't know the reason 
> behind the postponing, but who would expect one can't declare a 
> parameter with an alias if it's a template?! Speaking of 
> inconsistency.

At the bottom of the DIP you can find a link to the first 
community review round and a summary of the feedback. You'll see 
the DIP author decided he needed to do more work on the it.

Ultimately, he decided he didn't have a deep enough understanding 
to complete the DIP without some research, but he was too busy to 
make that investment. I suggested we mark it as postponed until 
he could come back to it. Reviewing our conversation, he was 
willing to someone else taking it over. So if anyone is willing, 
I don't need to wait on a response from him to make that happen.

> I'm sure there are bigger issues out there to be solved, but 
> it's quite disencouraging if such a significant improvement(or 
> rather fix) stays ignored.

Everyone rates issues differently. What's significant to one 
person won't be to another. There is much, much work to be done 
on shoring up holes in existing systems and solving problems the 
language maintainers believe to be significant, but resources are 
limited. So some things will inevitably be left to one side until 
someone picks them up.

For issues that are bugs or minor enhancements, we now have 
Razvan Nitu and Dennis Korpel in part-time positions funded by 
Symmetry Investments. They manage our issues database and our 
pull request queues. You can always ping one of them about any 
particular issue that doesn't require a DIP. This has been a huge 
change for the better. It means issues and PRs are much less 
likely to stagnate.

For something like your issue, which is a modification of the 
specification, a DIP is required. And that means either writing 
one or finding someone willing to write one and see it through to 
the end of the process. This isn't like managing bugs and pull 
requests. We simply don't have enough people on board to work on 
things like this. So it has to be done by interested parties in 
the community.

I wouldn't expect you to take over DIP 1023 yourself since you're 
new to the language, but if it's important enough to you, perhaps 
you can find someone to champion it, given a little time. Maybe 
the original author would be willing to pick it up again.