https://issues.dlang.org/show_bug.cgi?id=17746

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=17736

--

https://issues.dlang.org/show_bug.cgi?id=17746

Jack Stouffer <jack@jackstouffer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=14673

--

https://issues.dlang.org/show_bug.cgi?id=17746

Jack Stouffer <jack@jackstouffer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jack@jackstouffer.com
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--

https://issues.dlang.org/show_bug.cgi?id=17746

--- Comment #1 from Jack Stouffer <jack@jackstouffer.com> ---
>From my initial investigation into this, adding ref counting to BigInt is much
more complicated than it first appears. Adding a size_t ref count on the heap for BigUint basically breaks the rest of BigInt because anytime BigInt is const/immutable it makes the pointer to the reference count const/immutable as well. Meaning, const(BigInt) is no longer implicitly convert-able to BigInt. I'm not sure this is doable without a large rewrite.

--

https://issues.dlang.org/show_bug.cgi?id=17746

--- Comment #2 from hsteoh@quickfur.ath.cx ---
If the BigInt is const, then the best we can do is to create a new BigInt to hold the result of the operation, i.e., what BigInt does now.  For the optimization to have significant benefits, we pretty much require mutable BigInt.  So one approach could be that if the BigInt is const/immutable, just do what we do today (allocate a new BigInt to hold the result), otherwise perform write-in-place optimization.

So the following approach *might* work:

- When performing an operation, if the operand is const or immutable, revert to current behaviour (i.e., make a new BigInt to hold the result).

- When assigning to/from a const(BigInt) or immutable(BigInt), always make a copy of the source. There's pretty much no choice when assigning from a const(BigInt), because you can't update the refcount through the const reference. Copying is also required when assigning to const(BigInt) because otherwise you could assign mutable x to const y, then mutate x through the mutable reference, which breaks by-value semantics when viewed through y.

- If assigning mutable BigInts to each other, update the reference count and copy by reference instead.

- When performing an operation on mutable BigInt, if the refcount > 1, revert to current behaviour (allocate a new BigInt to hold the result). If the refcount == 1, then mutate in-place where possible.

--

https://issues.dlang.org/show_bug.cgi?id=17746

--- Comment #3 from Jack Stouffer <jack@jackstouffer.com> ---
On the other hand, if the COW is to avoid issues in code like this

```
BigInt a = 10;
BigInt b = a;

++a;
assert(b == 10);
```

where b could end up equaling 11, can we just make opAssign and the this(T : BigInt) copy the data array, and have everything else just use the in-place data?

--

https://issues.dlang.org/show_bug.cgi?id=17746

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--