What are the worst parts of D?

[Don via Digitalmars-d]

On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright 
wrote:
> On 9/24/2014 7:56 AM, Don wrote:
>> For example: We agreed *years* ago to remove the NCEG 
>> operators. Why haven't
>> they been removed yet?
>
> They do generate a warning if compiled with -w.

They should be gone completely. So should built-in sort.
I think there's something important that you haven't grasped yet. 
It was something I didn't really appreciate before working here.

  ** Keeping deprecated features alive is expensive. **

As long as deprecated features still exist, they impose a cost. 
Not just on the language maintainers, but also on the users. On 
anyone writing a language parser - so for example on text 
editors. On anyone training new employees.
And there's a little cognitive burden on all language users.

>
>>> What change in particular?
>> I've got a nasty feeling that you misread what he wrote. Every 
>> time we say,
>> "breaking changes are good", you seem to hear "breaking 
>> changes are bad"!
>
> It would be helpful having a list of what breaking changes you 
> had in mind.

C-style declarations. Builtin sort and reverse. NCEG operators. 
Built-in complex types. float.min. @property.

Basically, anything where it has been decided that it should be 
removed. Some of these things have been hanging around for six 
years.

I'd also like to see us getting rid of those warts like 
assert(float.nan) being true. And adding a @ in front of pure, 
nothrow.

Ask yourself, if D had no users other than you, so that you break 
*anything*, what would you remove? Make a wishlist, and then find 
out what's possible. Remember, when you did that before, we 
successfully got rid of 'bit', and there was practically no 
complaint.

Any breaking change where it fails to compile, and where there's 
an essentially mechanical solution, are really not a problem. 
Subtle changes in semantics are the ones that are disastrous.

We want to pay the one-off cost of fixing our code, so that we 
can get the long term return-on-investment of a cleaner language.