Ruling out arbitrary cost copy construction?

[Don]

dsimcha wrote:
> == Quote from Don (nospam at nospam.com)'s article
>> Andrei Alexandrescu wrote:
>>>> If anything, I'm inclined to say that we assume that the postblit is
>>>> O(1) and
>>>> let the programmer worry about any inefficiencies. We can point out
>>>> that anything
>>>> worse that O(1) will be a performance problem, but it seems to me that
>>>> any
>>>> attempt to either accomodate arbitrary cost postblit constructors or
>>>> to try and
>>>> use any kind of scheme which forces programmers to write postblits in
>>>> a certain
>>>> way is too complicated and doomed to failure. And even if it works, it
>>>> will be
>>>> highly annoying to deal with.
>>> It sure is annoying, but it does work.
>>>
>>> Don, can you estimate how difficult it would be to convert BigInt to a
>>> refcounted implementation?
>> At the moment, I think it's impossible.
>> Has anyone succesfully implemented refcounting in D? As long as bug 3516
>> (Destructor not called on temporaries) remains open, it doesn't seem to
>> be possible.
>> Is that the only blocker, or are there others?
> 
> Can someone please clarify something for me?  I thought BigInt was already COW
> (though I guess COW w/o ref counting is still pretty inefficient).

Yes, it's COW, but without refcounting. Which isn't really too terrible, 
because very few BigInt operations can be performed in-place. Even ++x 
can trigger a memory allocation.
The most important issues would be fixed with a small-value optimisation 
(values x where -long.max <= x <= long.max stored in the struct).