Comment #0 by bearophile_hugs — 2011-12-08T04:13:14Z
For uniformity with normal integers I'd like this D2 program to work:
import std.bigint;
void main() {
BigInt b = true;
}
But with dmd 2.057beta it gives:
...\dmd2\src\phobos\std\bigint.d(117): Error: operation not allowed on bool 'x'
I think an opAssign similar to this one solves the problem:
void opAssign(T: long)(T x)
{
static if (is(T == bool))
{
data = cast(ulong)x;
sign = false;
}
else
{
data = cast(ulong)((x < 0) ? -x : x);
sign = (x < 0);
}
}
Comment #1 by clugdbug — 2011-12-08T04:17:24Z
I don't think:
int x = true;
should compile. That looks like a bug to me (a relic of 'bit').
Comment #2 by bearophile_hugs — 2011-12-08T04:33:39Z
(In reply to comment #1)
> I don't think:
>
> int x = true;
>
> should compile. That looks like a bug to me (a relic of 'bit').
The 'bit' type has no relation with this problem.
In languages as Java and Pascal boolean values and integer values are two very distinct types. In languages like C/C++/D/Python boolean is a kind of subset of integer type. This means
int x;
bool b;
x = b; // OK, it's a subset
b = x; // error, generally
There are many situations where the implicit true -> 1 conversion is handy.
D accepts the implicit true -> 1 conversion in all cases. Refusing it only in BigInt assignements breaks the language simmetry. I don't think the implicit true -> 1 conversion will be removed from D2, so I think it should be present in BigInts too.
Comment #3 by clugdbug — 2011-12-09T01:34:20Z
(In reply to comment #2)
> (In reply to comment #1)
> > I don't think:
> >
> > int x = true;
> >
> > should compile. That looks like a bug to me (a relic of 'bit').
>
> The 'bit' type has no relation with this problem.
>
> In languages as Java and Pascal boolean values and integer values are two very
> distinct types. In languages like C/C++/D/Python boolean is a kind of subset of
> integer type.
Where did you get the idea that that applies to D? It was certainly true of 'bit', but bool is different.
> This means
>
> int x;
> bool b;
> x = b; // OK, it's a subset
> b = x; // error, generally
>
> There are many situations where the implicit true -> 1 conversion is handy.
Name one.
There are many uses for 1 -> true. But not the reverse. I can't see why:
int a = b > c; should compile.
> D accepts the implicit true -> 1 conversion in all cases.
Refusing it only in
> BigInt assignements breaks the language simmetry.
>I don't think the implicit true -> 1 conversion will be removed from D2,
This is what I disagree with. It's another evil implicit conversion.
Comment #4 by bearophile_hugs — 2011-12-09T03:13:08Z
(In reply to comment #3)
> > In languages as Java and Pascal boolean values and integer values are two
> > very distinct types. In languages like C/C++/D/Python boolean is a kind of
> > subset of integer type.
> Where did you get the idea that that applies to D?
This program compiles with -w too, a bool is accepted in many situations where you ask for an integer, like assignments and function arguments:
void foo(int x) {}
void main() {
bool b = true;
int y = b;
foo(b);
}
> > There are many situations where the implicit true -> 1 conversion is handy.
>
> Name one.
Counting true values:
void main() {
auto s1 = "hello";
auto s2 = "hallo";
int hamming_distance = 0;
assert(s1.length == s2.length);
foreach (i, c1; s1)
hamming_distance += c1 != s2[i];
assert(hamming_distance == 1);
}
In a Delphi/Java language you need something like:
if (c1 != s2[i]) hamming_distance++;
> There are many uses for 1 -> true.
Yet in D you need a cast to do it:
void main() {
int x = 1;
bool b = x;
}
test.d(3): Error: cannot implicitly convert expression (x) of type int to bool
> I can't see why:
>
> int a = b > c; should compile.
Because this is how D is designed, coming from C/C++. Languages like Pascal/Java that keep very apart integer and boolean types are OK, and I accept their design decisions, but D is not done this way, and I think this will not change. This is why I think designing BigInt against the way the other parts of D language are designed is bad.
> >I don't think the implicit true -> 1 conversion will be removed from D2,
>
> This is what I disagree with. It's another evil implicit conversion.
If this implicit conversion will be removed from D, then I agree that it will be right for BigInt too to forbid it. But the right thing for BigInt is to act like normal D ints (where possible and meaningful).
This is not a BigInt battle, it's a battle to remove implicit conversions in normal D ints, and its place is in D newsgroups and another enhancement request.
Comment #5 by clugdbug — 2011-12-23T02:29:18Z
You have the assumption that BigInt should be a drop-in replacement for int in all cases. That's a wrong assumption. It's NOT EVEN POSSIBLE.
For example, implicit conversions that involve range checking.
Here, you're asking for support for bad coding practices that are usually bugs.