www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7079] New: BigInt bool assign

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7079





 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7079






 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 09 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7079






 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 09 2011
prev sibling parent d-bugmail puremagic.com writes:
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