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.
