On Thursday, 4 July 2019 at 16:31:11 UTC, Patrick Schluter wrote:
> On Thursday, 4 July 2019 at 15:30:59 UTC, wjoe wrote:
> [snip good arguments]
>
>> or even better - the C way. Is it 0, or else...
>> This is completely predictable unlike the bool b = void; can be true and false at the same time.
>
> that's the issue. D's bool type follows exactly C (C has bool since C99) and C++ way. bool b; will behave exactly like your bool b = void;

I wouldn't know. I've used C before that came to pass. But from what I read online it doesn't behave exactly the same way. Like not at all.

But for clarification. What I was referring to was using an integer in place of a Boolean.

>>
>> The whole point of a Boolean data type is that it's something in its own right and decoupled from the implementation. Otherwise it's a redundancy.
>>
>> But then, IMHO, Boolean is almost always best to be replaced by something more expressive like std.typecons.Flag
>>
>> On that note if there's something that can be removed from the D language, it's bool.
>
> Nope.

Yes.

On Friday, 5 July 2019 at 09:04:26 UTC, Patrick Schluter wrote:
> On Friday, 5 July 2019 at 03:10:06 UTC, Exil wrote:
>> On Thursday, 4 July 2019 at 16:31:11 UTC, Patrick Schluter wrote:
>>> that's the issue. D's bool type follows exactly C (C has bool since C99) and C++ way.
>>> bool b; will behave exactly like your bool b = void;
>>
>> It doesn't have the same behavior. Currently DMD's codegen is bad, sometimes it checks the entire byte value and other times it only checks the first bit. All C/C++ compilers I've used check the entire value, consistently.
>
> if the codegen does something like (x & 1) then it is indeed a BUG and should be corrected.

No. If bool is really a 1 bit integer then this generated code is correct.

Since there are no 1 bit registers the compiler must use a bigger one for a 1 bit integer.
The resulting behavior when storing values > 1 into this int1 is akin to an integer overflow hence it's not a bug.

On Friday, 5 July 2019 at 09:04:26 UTC, Patrick Schluter wrote:
> On Friday, 5 July 2019 at 03:10:06 UTC, Exil wrote:
>> On Thursday, 4 July 2019 at 16:31:11 UTC, Patrick Schluter wrote:
>>> that's the issue. D's bool type follows exactly C (C has bool since C99) and C++ way.
>>> bool b; will behave exactly like your bool b = void;
>>
>> It doesn't have the same behavior. Currently DMD's codegen is bad, sometimes it checks the entire byte value and other times it only checks the first bit. All C/C++ compilers I've used check the entire value, consistently.
>
> if the codegen does something like (x & 1) then it is indeed a BUG and should be corrected.

Bug because it is inefficient or incorrect?
To the best of my knowledge C does only mandate that _Bool must be able to store 0 and 1, and  imposes no requirements on how other representations have to be treated. GCC treats _Bool as having 2 valid representations and 254 trap representations, so x == 1, x & 1 and x > 0 are all necessarily equivalent given this assumption. Not sure about Clang, in my quick test it always only checked the least significant bit.

Does D really not have more specific requirements for bool? (Does D even allow anything to have trap representations? There doesn't really seem to be any info on that)

On Friday, 5 July 2019 at 21:45:00 UTC, lithium iodate wrote:
> On Friday, 5 July 2019 at 09:04:26 UTC, Patrick Schluter wrote:
>> On Friday, 5 July 2019 at 03:10:06 UTC, Exil wrote:
>>> On Thursday, 4 July 2019 at 16:31:11 UTC, Patrick Schluter wrote:
>>>> that's the issue. D's bool type follows exactly C (C has bool since C99) and C++ way.
>>>> bool b; will behave exactly like your bool b = void;
>>>
>>> It doesn't have the same behavior. Currently DMD's codegen is bad, sometimes it checks the entire byte value and other times it only checks the first bit. All C/C++ compilers I've used check the entire value, consistently.
>>
>> if the codegen does something like (x & 1) then it is indeed a BUG and should be corrected.
>
> Bug because it is inefficient or incorrect?
> To the best of my knowledge C does only mandate that _Bool must be able to store 0 and 1, and  imposes no requirements on how other representations have to be treated.

The standard says that other bit representations in the bool variable (uninitialised) is "undefined behaviour", so there is no further point in discussing about the validity of what the compilers do after that.

> GCC treats _Bool as having 2 valid representations and 254 trap representations, so x == 1, x & 1 and x > 0 are all necessarily equivalent given this assumption. Not sure about Clang, in my quick test it always only checked the least significant bit.
>
> Does D really not have more specific requirements for bool? (Does D even allow anything to have trap representations? There doesn't really seem to be any info on that)

I played around a bit on godbolt and indeed the only compiler doing the (x & 1) test is llvm in non-optimized code, be it via ldc or via clang in C and C++. When optimizing it generates code that is more or less same as the other compilers but tries in most cases to only check the value of bit 0.
The other compilers are all over the place and sometimes they will generate code that assumes the value is only in bit 0, sometimes not, i.e. any non null value in the register will be seen as true and in other cases not.
Conclusion: as the C standard says, undefined behaviour and anything can happen.

On 7/4/2019 10:47 PM, Jonathan M Davis wrote:
> Walter and Andrei
> have already talked about how the spec needs to be improved such that it's
> more on par with what you have with a language like C++, but specs really
> aren't something that Walter's good at, which is a lot of why we don't have
> a better spec. So, if you have improvements for the spec, feel free to
> create PRs.

I can't get anyone to pull my spec improvements, so my work on that just kinda ran out of steam.

https://github.com/dlang/dlang.org/pulls/WalterBright

On Saturday, July 6, 2019 12:10:50 AM MDT Walter Bright via Digitalmars-d wrote:
> On 7/4/2019 10:47 PM, Jonathan M Davis wrote:
> > Walter and Andrei
> > have already talked about how the spec needs to be improved such that
> > it's more on par with what you have with a language like C++, but specs
> > really aren't something that Walter's good at, which is a lot of why we
> > don't have a better spec. So, if you have improvements for the spec,
> > feel free to create PRs.
>
> I can't get anyone to pull my spec improvements, so my work on that just kinda ran out of steam.
>
> https://github.com/dlang/dlang.org/pulls/WalterBright

I suspect that almost no one pays attention to PRs for the spec, meaning that the number of reviewers is even lower than it is for other repos, and we already have a problem with too few people reviewing stuff in general. I really should figure out how to find more time to spend on stuff like this.

- Jonathan M Davis

Sorry old thread I know, but I just got hit by an implicit bool to long conversion bug today, it's been a recurring theme over the years, so I checked in to see if anything had finally been changed to address the recurring bool issue and found this thread which is relatively recent, and also DIP 1015 that was rejected.

Perhaps the best solution, is rather than attempting to change what are deeply ingrained and polarised concepts surrounding the existing quasi bool/integral type, is a DIP proposing the addition of a new formally defined boolean type that would leave the existing bool type in place unchanged, no compromises have to be made, and no legacy code will have to be broken.

Any thoughts on if there may be at least some possible open minded support by the two guys who have the veto power?

On Wed, Sep 18, 2019 at 8:10 AM Rob T via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Sorry old thread I know, but I just got hit by an implicit bool to long conversion bug today, it's been a recurring theme over the years, so I checked in to see if anything had finally been changed to address the recurring bool issue and found this thread which is relatively recent, and also DIP 1015 that was rejected.
>
> Perhaps the best solution, is rather than attempting to change what are deeply ingrained and polarised concepts surrounding the existing quasi bool/integral type, is a DIP proposing the addition of a new formally defined boolean type that would leave the existing bool type in place unchanged, no compromises have to be made, and no legacy code will have to be broken.
>
> Any thoughts on if there may be at least some possible open minded support by the two guys who have the veto power?
>

You can do this on your own, just make your own Boolean type, or it could be added to Phobos, in theory it is there already: https://dlang.org/phobos/std_typecons.html#.Flag.Flag

On Wed, Sep 18, 2019 at 10:06 AM Daniel Kozak <kozzi11@gmail.com> wrote:
>
>
> You can do this on your own, just make your own Boolean type, or it could be added to Phobos, in theory it is there already: https://dlang.org/phobos/std_typecons.html#.Flag.Flag

import std.stdio;
import std.typecons;
alias MyBool = Flag!"mybool";
alias True = Flag!"mybool".yes;
alias False = Flag!"mybool".no;

void main()
{
    MyBool a = True;
    writeln(a);
}

On Wed, Sep 18, 2019 at 10:13 AM Daniel Kozak <kozzi11@gmail.com> wrote:
>...
> alias MyBool = Flag!"mybool";
> alias True = Flag!"mybool".yes;
> alias False = Flag!"mybool".no;
> ...

alias MyBool = Flag!"mybool";
alias True = MyBool.yes;
alias False = MyBool.no;