Does D have too many features?

[Walter Bright]

On 4/30/2012 10:04 AM, Jonathan M Davis wrote:
> I never claimed that I _was_ Walter. I was pointing out that there's very
> little consensus in this thread (almost all of the comments are in conflict
> with other comments) so that even if it was our intention to go and remove
> things from the language based on this thread, there is very little, if
> anything, that has a clear consensus on being removed. The closest would
> probably be the comma operator, and there wasn't even a complete consensus on
> _that_.

There is less agreement than I thought there would be.

This thread also generated far more interest than I anticipated.

> And while I obviously can't say for certain what Walter intended, it was my
> impression that the point of this thread was more out of curiosity and for
> "lessons learned" from designing D than to actually make any changes to the
> language right now (especially when you consider how much Walter hates
> breaking backwards compatibility). But obviously, he'd have to clarify for us
> to know for sure.

The first thing to emphasize is that NONE of this will happen for D2. The 
emphasis on D2 is fixing implementation and toolchain issues. Breaking existing 
code is off the table unless we are pretty much forced to in order to fix some 
other more important issue.

So we're talking several years out.

The evolution of C++ is interesting. So far, the C++ committee has shown 
incredible resistance to removing, or even deprecating, some features that 
pretty much everyone knows were a mistake, all in the interests of maintaining 
backwards compatibility. Some of C++'s success can be attributed to that, but 
also some of its endemic failures.

Where's the line to draw between breaking existing code and modernizing / 
removing cruft / removing support for features that promote bad code? Of
course, there can't be any fixed rule for that. Hearing peoples' opinions on it 
on a case by case basis helps a lot.

We've had some success in deprecating mistaken features - the bit data type, and 
typedefs.

I'm surprised nobody has mentioned opApply. That was a good idea at the time, 
but Ranges are a superior solution. I'd like to see new code not use opApply. 
It's a dead end, though it'll still be supported for a long time.