On Thursday, 7 November 2013 at 20:16:46 UTC, Jonathan M Davis
wrote:
With regards to the cost/benefit ratio, such a change fails
miserably. This is
exactly the sort of change that Walter and Andrei were talking
about stopping
completely at dconf, precisely because it doesn't actually fix
anything.
Breaking changes need to provide real, tangible benefits which
are greater than
the cost that they incur. And while I tend to agree that it
would be better
had none of the built-in attributes used @, changing it won't
fix any bugs and
won't make any software easier to mantain save perhaps for a
tool which
lexes/parses the language, and handling the few built-in
attributes with @ is
trivial in that case. The benefits are aesthetic, and changing
it requires
changing pretty much all existing D code. And even if you can
avoid having the
change break code immediately, it still requires changing the
code, so it's
not like that eliminates the cost of the change. It just
spreads it out.
If you want anything like this to happen, you'll have to
convince Walter and
Andrei, and I would be shocked if they were ever convinced.
They want to focus
on stability, not on tweaking everything in search of making
the language
perfect. Breaking changes - especially breaking changes on this
scale - need
to provide real, tangible benefits which outweigh the cost of
the breakage. And
changing the @ attributes doesn't even come close.
- Jonathan M Davis
I would add that constant breaking changes make the language
unfit for industrial usage in the long term.
Let's remember that D is being pushed in production by Andrei at
Facebook. If the language breaks everything at each release,
there is no way Facebook or any other company for that matter is
going to bet a dime on it.
