digitalmars.D.bugs - [Issue 7079] New: BigInt bool assign
- d-bugmail puremagic.com (37/37) Dec 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7079
- d-bugmail puremagic.com (12/12) Dec 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7079
- d-bugmail puremagic.com (19/24) Dec 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7079
- d-bugmail puremagic.com (13/36) Dec 09 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7079
- d-bugmail puremagic.com (43/57) Dec 09 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7079
- d-bugmail puremagic.com (14/14) Dec 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7079
http://d.puremagic.com/issues/show_bug.cgi?id=7079 Summary: BigInt bool assign Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc 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); } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 08 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7079 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au I don't think: int x = true; should compile. That looks like a bug to me (a relic of 'bit'). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 08 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7079I 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 08 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7079Where did you get the idea that that applies to D? It was certainly true of 'bit', but bool is different.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.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 inBigInt 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 09 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7079In 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); }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 situations where the implicit true -> 1 conversion is handy.Name one.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 boolI 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.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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------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.
Dec 09 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7079 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 23 2011