import std;

enum E : int { zer, one, two };

auto fn( long a ) { writeln( typeof(a).stringof, " ", a ); return a; }
auto fn( bool a ) { writeln( typeof(a).stringof, " ", a ); return a; }

void main() {
    writeln( typeof(0).stringof, " ", 0.sizeof );
    writeln( typeof(1).stringof, " ", 1.sizeof );
    writeln( typeof(E.two).stringof, " ", E.two.sizeof );

    fn( 0 );
    fn( 1 );
    fn( 2 );
    fn( E.zer );
    fn( E.one );
    fn( E.two );
}


prints:
>>>>>>>>>>>>>>>>>>>
int 4
int 4
E 4
bool false
bool true
long 2
bool false
bool true
long 2
<<<<<<<<<<<<<<<<<<<

first WTF?
why called with bool? 1 is int32 as D printed. E is at least int2 but with explicitly base type as int it is int32 too.
why bool?
why D ignores integral promotion that moves to bigger size or unsigned same size?

okey. probably bool is int1 and finita la comedia! (one man (Simon?) says that)

bool b = 0;
writeln( ++b ); // Error: operation not allowed on bool b += 1

second WTF?
so, what bool is?
is this int1? why others promotes to less size and why disallow ++ for int1?
is this a "real" boolean? why others promotes to it?

imo
- if some datatypes used as condition they implicitly converts to bool - ok
- funcs that accept bools should be checked/searched in the end as last choice. in case where exists other alternatives to bool it should be selected.

Please make a system for voting. Give to Walter 100 votes but not 99% of all votes as it is now. And let's vote for adequate non brainf*king behavior.

On Tuesday, 2 July 2019 at 12:06:00 UTC, a11e99z wrote:
> import std;
>
> enum E : int { zer, one, two };
>
> [...]

Looks like a serious bug to me. Please report it at https://issues.dlang.org/

On Tuesday, 2 July 2019 at 13:42:28 UTC, 9il wrote:
> [snip]
>
> Looks like a serious bug to me. Please report it at https://issues.dlang.org/

According to the section on function overloading [1], this is a "match with implicit conversions." Numeric literals like 0 and 1 can be implicitly converted to bool [2], so that isn't a bug, even if it is confusing in this case.

I think people could disagree on whether the enum part of the example is a bug. Maybe more of an enhancement request to have different handling for function overloads with enums? The enum values are being treated like literals instead of as ints.



[1] https://dlang.org/spec/function.html#function-overloading
[2] https://dlang.org/spec/type.html#bool

On Tuesday, 2 July 2019 at 15:10:37 UTC, jmh530 wrote:
> [snip]

Just realized that pretty much exactly this example with enums is in the DIP 1015 text...

On Tuesday, 2 July 2019 at 15:10:37 UTC, jmh530 wrote:
> On Tuesday, 2 July 2019 at 13:42:28 UTC, 9il wrote:

> I think people could disagree on whether the enum part of the example is a bug. Maybe more of an enhancement request to have different handling for function overloads with enums? The enum values are being treated like literals instead of as int

for one type called different functions. its very, very, very weird. its impossible in any other langs probably. imo should be fixed.
for enums with base types not bool functions with bool should never be called at all

On Tuesday, 2 July 2019 at 12:06:00 UTC, a11e99z wrote:
> import std;
>
> enum E : int { zer, one, two };
>
> auto fn( long a ) { writeln( typeof(a).stringof, " ", a ); return a; }
> auto fn( bool a ) { writeln( typeof(a).stringof, " ", a ); return a; }
>
> void main() {
>     writeln( typeof(0).stringof, " ", 0.sizeof );
>     writeln( typeof(1).stringof, " ", 1.sizeof );
>     writeln( typeof(E.two).stringof, " ", E.two.sizeof );
>
>     fn( 0 );
>     fn( 1 );
>     fn( 2 );
>     fn( E.zer );
>     fn( E.one );
>     fn( E.two );
> }
>
>
> prints:
>>>>>>>>>>>>>>>>>>>>
> int 4
> int 4
> E 4
> bool false
> bool true
> long 2
> bool false
> bool true
> long 2
> <<<<<<<<<<<<<<<<<<<
>
> first WTF?
> why called with bool? 1 is int32 as D printed. E is at least int2 but with explicitly base type as int it is int32 too.
> why bool?
> why D ignores integral promotion that moves to bigger size or unsigned same size?
>
> okey. probably bool is int1 and finita la comedia! (one man (Simon?) says that)
>
> bool b = 0;
> writeln( ++b ); // Error: operation not allowed on bool b += 1
>
> second WTF?
> so, what bool is?
> is this int1? why others promotes to less size and why disallow ++ for int1?
> is this a "real" boolean? why others promotes to it?
>
> imo
> - if some datatypes used as condition they implicitly converts to bool - ok
> - funcs that accept bools should be checked/searched in the end as last choice. in case where exists other alternatives to bool it should be selected.
>
> Please make a system for voting. Give to Walter 100 votes but not 99% of all votes as it is now. And let's vote for adequate non brainf*king behavior.

https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s

This isn't likely to change.

Some more discussion here:

https://forum.dlang.org/thread/bareupbeyubtmyorxqcz@forum.dlang.org?page=1

On 02.07.19 15:42, 9il wrote:
> On Tuesday, 2 July 2019 at 12:06:00 UTC, a11e99z wrote:
>> import std;
>>
>> enum E : int { zer, one, two };
>>
>> [...]
> 
> Looks like a serious bug to me. Please report it at https://issues.dlang.org/

It is not a bug in the implementation.
The attempted spec fix has been turned down:
https://forum.dlang.org/post/xkfgbfhhtkiewfqqsvcv@forum.dlang.org

On Tuesday, July 2, 2019 6:06:00 AM MDT a11e99z via Digitalmars-d wrote:
> import std;
>
> enum E : int { zer, one, two };
>
> auto fn( long a ) { writeln( typeof(a).stringof, " ", a ); return
> a; }
> auto fn( bool a ) { writeln( typeof(a).stringof, " ", a ); return
> a; }
>
> void main() {
>      writeln( typeof(0).stringof, " ", 0.sizeof );
>      writeln( typeof(1).stringof, " ", 1.sizeof );
>      writeln( typeof(E.two).stringof, " ", E.two.sizeof );
>
>      fn( 0 );
>      fn( 1 );
>      fn( 2 );
>      fn( E.zer );
>      fn( E.one );
>      fn( E.two );
> }
>
>
> prints:
>
> int 4
> int 4
> E 4
> bool false
> bool true
> long 2
> bool false
> bool true
> long 2
> <<<<<<<<<<<<<<<<<<<
>
> first WTF?
> why called with bool? 1 is int32 as D printed. E is at least int2
> but with explicitly base type as int it is int32 too.
> why bool?
> why D ignores integral promotion that moves to bigger size or
> unsigned same size?
>
> okey. probably bool is int1 and finita la comedia! (one man
> (Simon?) says that)
>
> bool b = 0;
> writeln( ++b ); // Error: operation not allowed on bool b += 1
>
> second WTF?
> so, what bool is?
> is this int1? why others promotes to less size and why disallow
> ++ for int1?
> is this a "real" boolean? why others promotes to it?
>
> imo
> - if some datatypes used as condition they implicitly converts to
> bool - ok
> - funcs that accept bools should be checked/searched in the end
> as last choice. in case where exists other alternatives to bool
> it should be selected.
>
> Please make a system for voting. Give to Walter 100 votes but not 99% of all votes as it is now. And let's vote for adequate non brainf*king behavior.

Basically, unlike most of us, Walter doesn't see any real difference between a bit and a bool even conceptually and thus thinks bool should just be a one bit integer type. So, for the most part, that's actally how bool works in D. At some point, either someone convinced him to make ++ illegal on bools or managed to get a PR in that did, and as I understand it, he regrets that that happened. DIP 1015 was proposed to fix how bool works so that it's no longer treated like an integer type, but Walter and Andrei rejected it. It's been discussed to death already, and it's clearly not going to change. As is the case with many (most?) languages, ultimately, language decisions in D are not a democracy. D is Walter's language, and he has the final say. He frequently has made great decisions with D. Many of us do not think that he did in particular this case, but it's still his decision, and it's quite clear at this point that he's not going to change his mind on this topic. So, if you want to use D, you're basically just going to have to learn to put up with the idea that bool is effectively bit.

- Jonathan M Davis

On Tuesday, 2 July 2019 at 17:04:24 UTC, Jonathan M Davis wrote:
> On Tuesday, July 2, 2019 6:06:00 AM MDT a11e99z via Digitalmars-d wrote:
>> [...]
>
> Basically, unlike most of us, Walter doesn't see any real difference between a bit and a bool even conceptually and thus thinks bool should just be a one bit integer type. So, for the most part, that's actally how bool works in D. At some point, either someone convinced him to make ++ illegal on bools or managed to get a PR in that did, and as I understand it, he regrets that that happened. DIP 1015 was proposed to fix how bool works so that it's no longer treated like an integer type, but Walter and Andrei rejected it. It's been discussed to death already, and it's clearly not going to change. As is the case with many (most?) languages, ultimately, language decisions in D are not a democracy. D is Walter's language, and he has the final say. He frequently has made great decisions with D. Many of us do not think that he did in particular this case, but it's still his decision, and it's quite clear at this point that he's not going to change his mind on this topic. So, if you want to use D, you're basically just going to have to learn to put up with the idea that bool is effectively bit.
>
> - Jonathan M Davis

I'm new to this discussion, but:

Can we fix the implementation and the spec, then? Walter's opinion is
clear, so can we move on? People are still free to write a new DIP to
convince the language maintainers, but the current state of bool seems
inconsistent.

This is in the spec[1] but fails for bool:

    assert(T.max + 1 == T.min, T.stringof);
    assert(T.min - 1 == T.max, T.stringof);

The spec also doesn't[2] consider `true` and `false` to be integer
literals, yet they are of type bool and they can be used as the rhs of
an int assignment. The grammar currently doesn't even consider them to
be literals[3].

Why do complement expressions[4] not work on bool?

To me something feels clearly wrong here.

[1] https://dlang.org/spec/expression.html#add_expressions (paragraph 7)
[2] https://dlang.org/spec/lex.html#IntegerLiteral
[3] https://dlang.org/spec/grammar.html#PrimaryExpression
[4] https://dlang.org/spec/expression.html#complement_expressions

On Tuesday, 2 July 2019 at 17:43:27 UTC, Les De Ridder wrote:
> On Tuesday, 2 July 2019 at 17:04:24 UTC, Jonathan M Davis wrote:
>> [...]
> Can we fix the implementation and the spec, then?

+1

Either make bool a real boolean type and disallow implicit conversions, or make it a true 1-bit integer type that actually behaves like all the other int types.
It's confusing as heck right now.