On 30-04-2012 21:50, Walter Bright wrote:
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.
I think what we need is an article on ranges on dlang.org (I can't find
one). They seem like a rather foreign concept when you come from other
languages, like array slices, and need a proper introduction.
--
- Alex
