BigInt bool assign

[Timon Gehr]

My post seems to have been lost because of NG malfunction.

On 12/24/2011 09:17 AM, Don wrote:
>> On 24.12.2011 01:32, Timon Gehr wrote:
>>> On 12/23/2011 11:34 PM, Jonathan M Davis wrote:
>>>> On Friday, December 23, 2011 17:19:26 bearophile wrote:
>>>>> Derek Parnell:
>>>>>> I'm with Don on this one because a boolean and an integer are not the
>>>>>> same concept, and even though many programming languages implement
>>>>>> booleans using integers, it still doesn't make them the same thing.
>>>>>
>>>>> D doesn't implement booleans with integers, D has a boolean type. But D
>>>>> allows bools to implicitly cast to ints/longs.
>>>>
>>>> I'd actually argue that that's a mistake. Implicitly converting an int
>>>> to a
>>>> bool is one thing - that's useful in conditional expressions - but
>>>> converting
>>>> from bool to int is something else entirely. I see no reason to expand
>>>> that
>>>> problem into BigInt. _int_ shouldn't have it, let alone BigInt.
>>>>
>>>> - Jonathan M Davis
>>>
>>> A: "Um, so why does bool implicitly convert to int but not to BigInt?"
>>> B: "Because the language's design contains an error. It is a huge
>>> _problem_. Therefore we decided to keep it inconsistent. If you
>>> re-parenthesise your expression however, your code will compile."
>>> A: "Awesome!!"
>>
>> As I said when I closed that post, it is _impossible_ for BigInt to
>> always behave the same as int. One example:
>>
>> byte c = x & 0x7F;
>>
>> This compiles if x is an int. It doesn't compile if x is a BigInt.

This is a limitation of the language. No case can be made that this
conversion would not be desirable, and it is an issue that is not
related a lot to what is being discussed in this thread.

By the way, is this also the rationale for why BigInt and long/ulong
cannot be compared for equality?

>>
>> BigInt's job is to behave like a Euclidean integer, not to be a drop-in
>> replacement for built-in integer types.
>>


It is not any more or any less valid to build an Euclidean integer from
a residue class than from a bool.

The main problem I have with bool -> int ok, int -> BigInt ok, bool ->
BigInt NG is that it kills the transitivity of the
implicitly-converts-to relation, not that I want to use BigInt as a
drop-in replacement for int.

By the way, bool does not implicitly convert to BigInt because
std.bigint contains a bug, not because it explicitly disallows it.

Negation does not work for bool therefore it does not compile even
though it would be unreachable code.

void opAssign(T: long)(T x) // T could be bool
{
     data = cast(ulong)((x < 0) ? -x : x); // does not work for bool
     sign = (x < 0);
}


This has other interesting implications:

struct S{
     long x;
     alias x this;
     void opUnary()(){}
}

void main() {
     import std.bigint;
     S s;
     BigInt x = s; // NG!
}