On Friday, 21 August 2015 at 21:50:21 UTC, Walter Bright wrote:
As with everything, it's cost/benefit. Changing isnan to isNaN
is an example of all cost and no benefit.
I've explained the benefits of changing factory() a couple
times in this thread. I believe the benefits are significant,
including the benefit of making D viable for use in embedded
systems.
This is fundamentally flawed way of thinking which only confirms
my feeling that my last DConf talk was a complete waste. You
completely ignore what those changes mean to your users by making
such statements.
Changing isnan to isNaN is a small benefit (better internal
structure and consistency is important) but it also comes at
tiny, almost insignificant costs. It doesn't cause any immediate
breakage and can be adjusted to at any moment with 1 simple
search/replace. It is a best kind of change you can have, tier 1
("good") in my classification.
Proposed change in Object.factory, on the other hand, is the
worst possible kind of breaking changes you can ever make (tier
3, "ugly") - it changes program semantics silently at runtime
with no errors and can't be adjusted to in automated manner,
requiring full reimplementation of some designs. Cost of this
change is huge, it will take no less than several full working
days to fix everything.
Benefits are also not small - Mike use case is very important.
Yet in current proposed form ration of cost/benefit is much much
worse than one of isnan/isNaN - simply because how big costs are.
To make the change more acceptable you can take one of two
possible paths:
1) make more benefits, for example by improving `export`
definition and unifying its semantics between platforms (see also
attribute inference / WPO proposals by Martin)
2) reduce costs by providing compiler diagnostics for transition
and enabling similar designs at CT (see the issue I have linked
earlier)
Doing both is perfection, of course.
