Object.factory() and exe file size bloat

[Dicebot via Digitalmars-d]

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.