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.
