Object.factory() and exe file size bloat

[Walter Bright via Digitalmars-d]

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.