On Monday, 29 April 2013 at 14:08:20 UTC, Mike James wrote:
>> gdc:
>>
>> bool x = false;
>> x++;
>>
>> main.d:50: Error: operation not allowed on bool 'x'
>>
>> why not? is just an integer after all. another special case?
>
> If you are going to create a boolean then use it as a boolean - it's not an integer any more. Don't mix and match - there's nothing worse than trying to follow some code that uses a variable in one way then, out of lazyness, uses it in a different way.

that was exactly my point. that a boolean *should not* be an integer. and the case that I presented shows just another inconsistency of the relationship between booleans and integers in D. it works one way when it comes to function overloading, and another way when it comes to, let's say, ++ operator.

On Sat, 27 Apr 2013 12:51:48 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/26/2013 7:36 PM, Mehrdad wrote:
>> Walter, you're completely missing the point.
>
> I completely understand it is a perception problem. Some people see bool as a 1 bit integer (including me). Some see bool as something very distinct from integers (including you).

short x = cast(short)0x10000;
assert(x == 0);

bool b = cast(bool)2;
assert(b == 1);  // NOT 2s complement

bool is not an integer.  It doesn't behave like any other integer type.  Because it has some power to implicitly cast to int, this does not make it an integer.

-Steve

On Monday, 29 April 2013 at 14:08:20 UTC, Mike James wrote:
>> gdc:
>>
>> bool x = false;
>> x++;
>>
>> main.d:50: Error: operation not allowed on bool 'x'
>>
>> why not? is just an integer after all. another special case?
>
> If you are going to create a boolean then use it as a boolean - it's not an integer any more. Don't mix and match - there's nothing worse than trying to follow some code that uses a variable in one way then, out of lazyness, uses it in a different way.
>
>>
>> this works:
>>
>> int x = false;
>> x++;

The main point made in this thread is that because bool is not really an integral type, you cannot use it as one, but D overloads integral types with bool which is clearly wrong. You also cannot in general interchange ints and bools inside a template without special conditions to differentiate between them the two (eg ++bool fails), therefore bool should not overload on ints or implicitly cast to/from ints and bools under most situations.

--rt

On Sat, 27 Apr 2013 13:27:39 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/26/2013 11:04 PM, Steven Schveighoffer wrote:
>> I think the issue (and I am firmly in the foo(1) => long camp) is that bools are
>> considered better integers than actual integer types (or even floating point
>> types for that matter).  I agree that bools can be implicitly cast to and from
>> integers, as a last resort.
>
> The overload system in D is explicitly not based on "better". (The C++ "better" overloading system is for functions, but not for templates.) The D overload system is based on partial ordering, which is the same as what C++ uses for templates.
>
> I don't know for a fact, but I'm pretty sure the partial ordering scheme that C++ selected for templates, which came along many years later, was picked because people realized it was better (and more mathematically robust and defensible).
>
> One of the problems with a "better" matching system is handling functions with multiple parameters, each with their own "better" match. (The C++ Standard devotes a great deal of complex text to this, it boils down to a bunch of rather arbitrary decisions.) Partial ordering solves this neatly and consistently.
>
> As one who implemented C++'s better matching system, I can confidently state that the partial ordering scheme is FAR better overall.

I think you are inventing a strawman problem that this bug solves.  There is no need for a "Better" scheme, partial ordering works great, and so do true and false.

bool isn't an integer.  It can implicitly cast to an integer, but that's it.  Once we implement that rule, everything falls into place.  If you want to pass a "true" boolean literal, use true.  If you want to pass a "false" boolean literal use false.  Using 1 and 0 may be convenient, and may also be valid, but when it matches an integral type as well as bool, then it's ambiguous.

-Steve

On Monday, April 29, 2013 09:54:40 Steven Schveighoffer wrote:
> On Sat, 27 Apr 2013 12:51:48 -0700, Walter Bright
> 
> <newshound2@digitalmars.com> wrote:
> > On 4/26/2013 7:36 PM, Mehrdad wrote:
> >> Walter, you're completely missing the point.
> > 
> > I completely understand it is a perception problem. Some people see bool
> > as a 1 bit integer (including me). Some see bool as something very
> > distinct from integers (including you).
> 
> short x = cast(short)0x10000;
> assert(x == 0);
> 
> bool b = cast(bool)2;
> assert(b == 1); // NOT 2s complement
> 
> bool is not an integer. It doesn't behave like any other integer type. Because it has some power to implicitly cast to int, this does not make it an integer.

It also isn't considered to be an integral type per std.traits.isIntegral. isIntegral only considers byte, ubyte, short, ushort, int, uint, long, and ulong to be integral types.

- Jonathan M Davis

Am 29.04.2013 19:10, schrieb Steven Schveighoffer:
> On Sat, 27 Apr 2013 13:27:39 -0700, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 4/26/2013 11:04 PM, Steven Schveighoffer wrote:
>>> I think the issue (and I am firmly in the foo(1) => long camp) is
>>> that bools are
>>> considered better integers than actual integer types (or even
>>> floating point
>>> types for that matter).  I agree that bools can be implicitly cast to
>>> and from
>>> integers, as a last resort.
>>
>> The overload system in D is explicitly not based on "better". (The C++
>> "better" overloading system is for functions, but not for templates.)
>> The D overload system is based on partial ordering, which is the same
>> as what C++ uses for templates.
>>
>> I don't know for a fact, but I'm pretty sure the partial ordering
>> scheme that C++ selected for templates, which came along many years
>> later, was picked because people realized it was better (and more
>> mathematically robust and defensible).
>>
>> One of the problems with a "better" matching system is handling
>> functions with multiple parameters, each with their own "better"
>> match. (The C++ Standard devotes a great deal of complex text to this,
>> it boils down to a bunch of rather arbitrary decisions.) Partial
>> ordering solves this neatly and consistently.
>>
>> As one who implemented C++'s better matching system, I can confidently
>> state that the partial ordering scheme is FAR better overall.
>
> I think you are inventing a strawman problem that this bug solves.
> There is no need for a "Better" scheme, partial ordering works great,
> and so do true and false.
>
> bool isn't an integer.  It can implicitly cast to an integer, but that's
> it.  Once we implement that rule, everything falls into place.  If you
> want to pass a "true" boolean literal, use true.  If you want to pass a
> "false" boolean literal use false.  Using 1 and 0 may be convenient, and
> may also be valid, but when it matches an integral type as well as bool,
> then it's ambiguous.
>
> -Steve

Fully agree, I still not understand what is the issue to support the boolean strong typing other languages do offer.

--
Paulo

On 4/29/2013 10:10 AM, Steven Schveighoffer wrote:
> On Sat, 27 Apr 2013 13:27:39 -0700, Walter Bright <newshound2@digitalmars.com>
> wrote:
>
>> On 4/26/2013 11:04 PM, Steven Schveighoffer wrote:
>>> I think the issue (and I am firmly in the foo(1) => long camp) is that bools are
>>> considered better integers than actual integer types (or even floating point
>>> types for that matter).  I agree that bools can be implicitly cast to and from
>>> integers, as a last resort.
>>
>> The overload system in D is explicitly not based on "better". (The C++
>> "better" overloading system is for functions, but not for templates.) The D
>> overload system is based on partial ordering, which is the same as what C++
>> uses for templates.
>>
>> I don't know for a fact, but I'm pretty sure the partial ordering scheme that
>> C++ selected for templates, which came along many years later, was picked
>> because people realized it was better (and more mathematically robust and
>> defensible).
>>
>> One of the problems with a "better" matching system is handling functions with
>> multiple parameters, each with their own "better" match. (The C++ Standard
>> devotes a great deal of complex text to this, it boils down to a bunch of
>> rather arbitrary decisions.) Partial ordering solves this neatly and
>> consistently.
>>
>> As one who implemented C++'s better matching system, I can confidently state
>> that the partial ordering scheme is FAR better overall.
>
> I think you are inventing a strawman problem that this bug solves.  There is no
> need for a "Better" scheme, partial ordering works great, and so do true and false.
>
> bool isn't an integer.  It can implicitly cast to an integer, but that's it.
> Once we implement that rule, everything falls into place.  If you want to pass a
> "true" boolean literal, use true.  If you want to pass a "false" boolean literal
> use false.  Using 1 and 0 may be convenient, and may also be valid, but when it
> matches an integral type as well as bool, then it's ambiguous.

Carefully reading your statement, you are still arguing that matching 1 to long should be "better" than matching it to bool.

On Sunday, 28 April 2013 at 13:38:53 UTC, Andrei Alexandrescu wrote:
[...]
> If enough differences accumulate to make bool quite a different type from a regular integral, then the matter of overloading with long, conversion from literals 1 and 0 etc. may be reopened. Even then, it would be a difficult decision.

I agree with most of what you said in your full post, except that in the quote above you are suggesting that there's a difficult decision to be made in the case of bool being it's own type rather than an integral type.

The opposite should be the case, where the decision to keep it as an integral is a difficult to defend.

I don't see where the difficulty is, because unless bool can exactly be treated as an integral, then it simply is not an integral, and unless it is an integral, it cannot be freely interchanged with the integrals.

The arguments in defense if bool as an integral are IMO weak.

For example, Walter mentioned the case of char successfully being treated as an integral type rather than a special case "char' type. However, are there any differences between what char does and what byte does that interfere with each other? If char performs exactly like a integral type, then you can convincingly argue that it is an integral type.

Can the same thing with char be said about bool? No. You can only say that bool does share some, but not all the characteristics if an integral.

The other argument in favor boils down to a matter of convenience under some circumstances. Yes, there are a few cases where it is advantageous to interchange boolean 'true' and 'false' with integral 1 and 0, however the vast majority of uses do not rely on such an interchange, and even if such interchanges are used often, bool still has significant differences of behavior that exclude it from being considered as a fully interchangeable integral type (eg truncation behavior and differences with operators).

The best you can argue for, is that under some situations, bool should be freely interchanged with regular integrals, however that's not going to be true for all cases.

The conclusion ought to be that unless bool can be adjusted into behaving exactly like all the other integrals, then it simply cannot be freely interchanged as an integral in all cases, i.e., maybe OK in some cases, but certainly not all.

--rt

On 4/29/2013 7:30 AM, deadalnix wrote:
>>
>> (that is: ifzero(), infnonzero(), whilezero(), whilenonzero()).
>>
>


int x = 3;
if (!!x)
{
	// do something
}


Its not official but this already works in the C like langauges, as a way to 'promote to bool'

On Monday, 29 April 2013 at 18:53:22 UTC, Sean Cavanaugh wrote:
> On 4/29/2013 7:30 AM, deadalnix wrote:
> Its not official but this already works in the C like langauges, as a way to 'promote to bool'

I know, but I still think that ifz() and ifnz() convey better (more, they are easier to debug, but that's subjective). However, is not a big deal.