The "no gc" crowd

[Joseph Rushton Wakeling]

On 10/10/13 20:28, H. S. Teoh wrote:
> I left some comments on these bugs. Basically, BigInt should not be
> implicitly castable from const/immutable to unqual, because unlike the
> built-in types, it's *not* a value type:
>
> 	BigInt x = 123;
> 	BigInt y = x;  // creates an alias to x's data.

    BigInt a = 2;
    BigInt b = a;
    b = 3;
    writeln(a);
    writeln(b);

... gives you:

    2
    3

So, even though there's an array hidden away inside std.BigInt, it still seems 
to copy via value.

> Of course, the way BigInt is implemented, any operation on it causes new
> data to be created (essentially it behaves like a copy-on-write type),
> so it's not as though you can directly modify immutable this way, but
> it breaks the type system and opens up possible loopholes.

I guess that explains my result above .... ?

> What you need to do is to use inout for functions that need to handle
> both built-in ints and BigInts, e.g.:
>
> 	inout(Num) abs(Num)(inout(Num) x) {
> 		return (x >= 0) ? x : -x;
> 	}
>
> This *should* work (I think -- I didn't check :-P).

I did, and it results in issues with BigInt's opCmp.  But that may say more 
about BigInt's opCmp than about your solution.

> Arguably, a *lot* of generic code involving numerical operations is
> broken, because they assume built-in types' behaviour of being
> implicitly convertible to/from immutable (due to being value types).

How would you suggest correcting that?