On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:

On 11/27/2012 5:52 AM, David Nadlinger wrote:

I agree, and if I remember previous discussions on the subject
correctly, it seems like only Walter is in favor of upholding the
current restrictions of "alias" parameters to symbols. I simply do not
see a point in pushing compiler implementation details on the user like
that – for the programmer, a type is a type is a type…

Walter, do you have an example of a situation where the alias parameter
restriction would be beneficial? (for the D code involved, I don't mean
the few lines of code avoided in the compiler)

In any case, it will break a great deal of existing code to change that behavior.

The discussed issue is one of those inconsistencies that make people struggle when using D. D's main selling point is rich metaprogramming. Others are rapidly catching up in the field of expressive native languages. If we set these early design decisions in stone, it means we will not be able to compete with them. And besides, are there many big proprietary D2 codebases that you afraid? I doubt there are. And Manu actually represents people who are willing to work on one, but are held off by these issues. Open source projects however will be easily fixable, and people using D will actually welcome these positive changes.

I feel this sentiment every day.

I'm more than happy to receive breaking changes that make the language tidier and more consistent. I'll happily take the time to keep our codebase up to date.

As a commercial entity, I'd rather see the language assert breaking changes that make the language feel more solid/robust than to continue implementing ugly hacks/workarounds for sake of not breaking our codebase.

Surely it's better to sweep the foundations while users range in the 4-5 digits, than the 6-7 digits (which is surely the hope here)?

There is a lot of nasty clutter/mess in the lowest level of D (and the useful parts should generally be wrapped up in std.traits anyway) ;)

Just look through std.traits at some of the wild approaches required to discover certain properties about things. Our code is equally riddled with stuff like that, though it's gotten a lot better in the past 2 months!