On 8/23/2015 2:27 AM, Dicebot wrote:
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.
I agree the cost is small, but the benefit is zero. Yes, I understand you (and
others) don't agree with my estimation of the benefit. I don't see much point in
debating that one further, it's a done deal.
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.
The point of this thread is to investigate the various ways of mitigating the
costs and figure out the best way forward.
