On Fri, 9 May 2003 13:38:39 +0000 (UTC), Mark T <Mark_member@pathlink.com> wrote:

> In article <b9f97v$28q9$1@digitaldaemon.com>, C. Sauls says...
>>
>> There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with the
>> constants 'true' and 'false'.
>
> Which many people in this forum think is a mistake.  Boolean is a type, a very
> common type used by most programmers, a bit is a unit of storage. It would be
> nice if Walter provided a standard Boolean type as well as bit type (just
> consider it syntactic sugar).
>
> Otherwise everyone will create some typedef variant for Boolean just like what
> was done in the C language up until C99 added 'bool'. Of course, thousands upon
> thousands of lines of C code with BOOL, BOOLEAN, boolean, etc already exist
> which makes it harder for people to maintain and understand.

Agreed.

A boolean value represents a position of truth - something is either true or false. A boolean value is one of two possible states.

A bit value can obviously used to emulate a boolean value because a bit value also has only two states. However, a bit value is a numeric value and can thus be used with arithmetic expressions. There are a lot of coders (myself included) that have used this artifact of bit (and aliased ints) to effect some coding trickery/wizardy. However, now that I've grown old and experienced, I learned that this sort of coding does NOT pay in the long term. Because of the cost of maintaining code, it is always better to be explicit and obvious about your intentions, rather than resorting to (smug?) tricks-of-the-trade.

By this I mean that if one 'needs' to use a boolean value in some arithmetic, then be explicit about it.

 bool x;
 int k;
 int z;
 x = someFunc( ... );
 if (x == TRUE)
 {
   k = 1;
 }
 else
 {
   k = 0;
 }

 z = A*k + B*(1-k);

There is no guess work about this now on the part of the reader. Note that some languages assume TRUE is -1 and others assume it is 1! Confusion reigns.

(Excuse the trivial nature of the example. In real life, one would do this very much more efficiently.)


-- 
Derek

> 2. There should be a separate boolean type.

Heartily agree

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EBD4A81.D4F35E8E@chello.at...
>
>
> Patrick Down wrote:
> >
> > In article <3EBBE410.EB530CA2@chello.at>, Helmut Leitner says...
> >
> > >
> > >alias bit boolean;
> > >
> >
> > There are two problems with the bit type that makes it inadequate as a boolean type. A bit can not be an inout or out parameter of a function and you can't slice a bit array arbitrarily.
> >
> > While I understand from an implementation point of view why bits have this restriction I belive that a type that is to be used as a boolean should not have the restrictions that bit currently has.
> >
> > For this reason I belive that either
> >
> > 1. The bit type needs to have it fuctionality expanded to include the capablities above.  ( With all the implementation baggage this brings.)
> >
> > --or--
> >
> > 2. There should be a separate boolean type.
>
> First of all, one could just as well chose
>   alias int boolean;
> or
>   type char boolean;
> although it seems not very logical.
>
> Apart from that I don't see much implementation problems with bit references and slices in itself. Bit addressing could just be address<<3+index.
>
> I suppose you mean the relationship between these and gc? As the gc must be reworked anyway these problems are bound together and maybe have to be solved together.
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

> First of all, one could just as well chose
>   alias int boolean;
> or
>   type char boolean;
> although it seems not very logical.

It should be a typedef, not an alias. Being able to mix and match booleans and other integrals without compiler complaints is not good

I agree with your thesis in the main. Often it is better to use an enumeration to control function behaviour (though we then get into whether to combine enumerators as flags in an integer parameter - this is a good thing, however, as it documents whether enumerators can/should be combined or not.)

However, the appropriateness of a boolean keyword does not rest only on whether it is useful as function parameters (which I would suggest it would be in any case), since:

class SomeContainer
{

    bool IsEmpty();
};

It either is empty or it's not, and we want that truth expressed as a boolean quantity.

boolean is also very useful for overloading methods, e.g. in serialisation.
It's pretty ugly (never mind confusing to user's of your code) when
(de-)serialising a boolean value to have to (un-)pack it as a
bit/char/short/etc.



"J. Daniel Smith" <J_Daniel_Smith@HoTMaiL.com> wrote in message news:b9grsl$ri8$1@digitaldaemon.com...
> There is an argument floating around somewhere (sorry, I can't find the exact reference I'm thinking of) that says boolean types are overused and often especially poor choices for function parameters.
>
> The problem is (at least) twofold: first, it's usually not obvious from
the
> function name itself how to set the flag.  Consider the pseudo-code
>    bool equal(string s1, string s2, bool ignore_case)
> you have to look at the argument name "ignore_case" to know exactly how to
> use equal().  Given that, wouldn't it be better to put this information in
> the function name itself such as
>    bool equalI(string s1, string s2);
>    bool equal(string s1, string s2);
> now it's clear that equalI() does a case-insensitive comparision.
>
> The other issue is that there really aren't that many parameters that are really boolean.  Keeping with this string comparison example, should
various
> UNICODE encodings be considered?  How about UNICODE combining characters? Should punctuation be ignored (when comparing names or addresses)?  The point is that often some type of enumeration should be used instead of a boolean argument.  This makes the purpose of the parameter much clearer, while at the same time making it easier to expand as the need arises.
>
>    Dan
>
> "C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:b9f97v$28q9$1@digitaldaemon.com...
> > There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with
the
> > constants 'true' and 'false'.
> >
> >  -- C. Sauls
> >
> >
>
>

It's not my thesis; but I do agree with the basic ideas and unfortunately I can't remember the reference.

The appropriateness of a keyword is related to how often "bool" would be used.  Sure, there are some uglinesses to deal with if there isn't a keyword, but if you don't deal with bools that much (as perhaps you shouldn't), then maybe it's not that big of a deal to have to put up with a few annoyances on occasion.

Your IsEmpty() example matches what I did for equal() and equalI(); a
function return value (as opposed to arguments) can be a more appropriate
use of booleans.

   Dan

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bah32r$dqb$4@digitaldaemon.com...
> I agree with your thesis in the main. Often it is better to use an enumeration to control function behaviour (though we then get into whether to combine enumerators as flags in an integer parameter - this is a good thing, however, as it documents whether enumerators can/should be combined or not.)
>
> However, the appropriateness of a boolean keyword does not rest only on whether it is useful as function parameters (which I would suggest it
would
> be in any case), since:
>
> class SomeContainer
> {
>
>     bool IsEmpty();
> };
>
> It either is empty or it's not, and we want that truth expressed as a boolean quantity.
>
> boolean is also very useful for overloading methods, e.g. in
serialisation.
> It's pretty ugly (never mind confusing to user's of your code) when
> (de-)serialising a boolean value to have to (un-)pack it as a
> bit/char/short/etc.
>
>
>
> "J. Daniel Smith" <J_Daniel_Smith@HoTMaiL.com> wrote in message news:b9grsl$ri8$1@digitaldaemon.com...
> > There is an argument floating around somewhere (sorry, I can't find the exact reference I'm thinking of) that says boolean types are overused
and
> > often especially poor choices for function parameters.
> >
> > The problem is (at least) twofold: first, it's usually not obvious from
> the
> > function name itself how to set the flag.  Consider the pseudo-code
> >    bool equal(string s1, string s2, bool ignore_case)
> > you have to look at the argument name "ignore_case" to know exactly how
to
> > use equal().  Given that, wouldn't it be better to put this information
in
> > the function name itself such as
> >    bool equalI(string s1, string s2);
> >    bool equal(string s1, string s2);
> > now it's clear that equalI() does a case-insensitive comparision.
> >
> > The other issue is that there really aren't that many parameters that
are
> > really boolean.  Keeping with this string comparison example, should
> various
> > UNICODE encodings be considered?  How about UNICODE combining
characters?
> > Should punctuation be ignored (when comparing names or addresses)?  The point is that often some type of enumeration should be used instead of a boolean argument.  This makes the purpose of the parameter much clearer, while at the same time making it easier to expand as the need arises.
> >
> >    Dan
> >
> > "C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:b9f97v$28q9$1@digitaldaemon.com...
> > > There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with
> the
> > > constants 'true' and 'false'.
> > >
> > >  -- C. Sauls
> > >
> > >
> >
> >
>
>

Hi.

It's Friday, and I've just had my third beer, which makes me nastier than usual.

In that spirit, re-reading the 'Boolean type' posts, I find I'm convinced that at least half of us will create little 'bool.d' files containing the single line:

alias bit bool;

If we can all agree that this is the standard definition, and that it lives in "bool.d", we can all write much more compatible code. Otherwise, I'll have to have something doppey like "mybool.d" containing the equally doppey "alias bit mybool;".

Anyone with me?  Shall we make it a defacto standard?

Bill

In article <3EFCA3B6.5010802@viasic.com>, Bill Cox says...
>
>Hi.
>
>alias bit bool;

Except mine would be

alias byte bool;

Sigh. I suppose we might as well take lemons and make lemonade out of the no boolean situation. Should that be an alias or a typedef though?

-Jon

In article <3EFCA3B6.5010802@viasic.com>, Bill Cox says...
>
>Hi.
>
>It's Friday, and I've just had my third beer, which makes me nastier than usual.
>
>In that spirit, re-reading the 'Boolean type' posts, I find I'm convinced that at least half of us will create little 'bool.d' files containing the single line:
>
>alias bit bool;
>
>If we can all agree that this is the standard definition, and that it lives in "bool.d", we can all write much more compatible code. Otherwise, I'll have to have something doppey like "mybool.d" containing the equally doppey "alias bit mybool;".
>
>Anyone with me?  Shall we make it a defacto standard?
>
>Bill
>

Jonathan Andrew wrote:
> Sigh. I suppose we might as well take lemons and make lemonade out of the no
> boolean situation. Should that be an alias or a typedef though?
> 
> -Jon
> 
> In article <3EFCA3B6.5010802@viasic.com>, Bill Cox says...
> 
>>Hi.
>>
>>It's Friday, and I've just had my third beer, which makes me nastier than usual.
>>
>>In that spirit, re-reading the 'Boolean type' posts, I find I'm convinced that at least half of us will create little 'bool.d' files containing the single line:
>>
>>alias bit bool;
>>
>>If we can all agree that this is the standard definition, and that it lives in "bool.d", we can all write much more compatible code. Otherwise, I'll have to have something doppey like "mybool.d" containing the equally doppey "alias bit mybool;".
>>
>>Anyone with me?  Shall we make it a defacto standard?
>>
>>Bill
>>
> 
> 
> 

Argh!  I don't care!  Byte is fine.  Typedef is fine.  I just want a 'bool' type so I can get mad when I see programmers adding bools and ints.  When I say bool, I mean bool.

Bill

P.S.  I'm into a bit of rum now, so please ignore me.