Does D have too many features?

[Alex Rønne Petersen]

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