1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We really shouldn't care how they are represented internally. Walter can do with it what he likes within the compiler. It's certainly syntactically cleaner to use true and false, regardless of what they represent under the hood.

2) Boolean should not be assigned a value other than another boolean; from another variable or from an expression. Straying from this rule should produce a compile-time error.

3) Boolean implementation should, where it makes a difference, strive for performance. This relates to both execution time and to memory usage. That is, if it's more efficient to implement a single boolean variable as a byte/int/float/class/whatever (under the covers), then let the compiler get on and do its thing. If, however, memory constraints are the primary factor then the compiler should at least provide a mechanism for the programmer to choose such a representation; the boolean[] is potentially an example. Those who argue that there's never a need (nowadays) to pack data into its smallest representable space simply have not /yet/ had the need to do so (it's the "640KB ought to be enough for anyone" argument taken to the 640MB level).

4) The usage of a boolean value as an arithmetic expression *RValue* has been around since almost the dawn of programming. It's convenient (and optimal) in many cases, though some might find the syntax uncomfortable. It's the kind of thing that comes in handy when bit-twiddling, or trying to eke out that last bit of whatever. One does not have to use it.

---------------------------

Given that; Walter's choice of a bit to represent boolean values is a fair one. After all, you only get two values for a bit value, right? Point 1, totally cool.

D bit variables can *currently* be assigned values other than true or false. This should be viewed as a bug, and nothing more. Point 2, way bogus.

As it stands, the bit implementation does indeed strive for performance when used standalone. In fact, it uses a byte. When bit is used as an array, the compiler switches strategies and packs them into the tightest space it can. This is fine for many cases, but it /might/ be better if it were programmer controllable. For example: I may wish to have a fast array of boolean values. Currently I'd personally implement this as a byte[], but then I've sacrificed some of the semantic notion of a boolean type. That's my choice, and one I rather the compiler helped me out with. On the other hand, a packed bit[] is a godsend for many, and it maintains boolean semantics. Point 3, mostly cool.

Bit twiddling and optimization are important to systems programmers. D is intended to cater to that audience. Point 4, cool.

-------------------------------

Additional Commentary:

Please, let's not get hung up on what the underlying implementation should be; that's missing the point.

Additionally, multiple **API-Level** definitions of what a boolean means should be avoided at all costs. That is, if you're writing a public API and you force users to apply your personal version of boolean (as method args, or whatever), then you're simply fracturing any possible resolution and confusing the hell out of potential users. In my humble opinion, that's an entirely selfish route to take. If you're going to be utterly selfless about sharing your code, why be utterly selfish about a clearly controversial issue at the same time?

- Kris

In article <c9nqcd$f21$1@digitaldaemon.com>, Kris says...
>
>1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We really shouldn't care how they are represented internally. Walter can do with it what he likes within the compiler. It's certainly syntactically cleaner to use true and false, regardless of what they represent under the hood.
>
>2) Boolean should not be assigned a value other than another boolean; from another variable or from an expression. Straying from this rule should produce a compile-time error.
>
>3) Boolean implementation should, where it makes a difference, strive for performance. This relates to both execution time and to memory usage. That is, if it's more efficient to implement a single boolean variable as a byte/int/float/class/whatever (under the covers), then let the compiler get on and do its thing. If, however, memory constraints are the primary factor then the compiler should at least provide a mechanism for the programmer to choose such a representation; the boolean[] is potentially an example. Those who argue that there's never a need (nowadays) to pack data into its smallest representable space simply have not /yet/ had the need to do so (it's the "640KB ought to be enough for anyone" argument taken to the 640MB level).
>
>4) The usage of a boolean value as an arithmetic expression *RValue* has been around since almost the dawn of programming. It's convenient (and optimal) in many cases, though some might find the syntax uncomfortable. It's the kind of thing that comes in handy when bit-twiddling, or trying to eke out that last bit of whatever. One does not have to use it.
>
>---------------------------
>
>Given that; Walter's choice of a bit to represent boolean values is a fair one. After all, you only get two values for a bit value, right? Point 1, totally cool.
>
>D bit variables can *currently* be assigned values other than true or false. This should be viewed as a bug, and nothing more. Point 2, way bogus.
>
>As it stands, the bit implementation does indeed strive for performance when used standalone. In fact, it uses a byte. When bit is used as an array, the compiler switches strategies and packs them into the tightest space it can. This is fine for many cases, but it /might/ be better if it were programmer controllable. For example: I may wish to have a fast array of boolean values. Currently I'd personally implement this as a byte[], but then I've sacrificed some of the semantic notion of a boolean type. That's my choice, and one I rather the compiler helped me out with. On the other hand, a packed bit[] is a godsend for many, and it maintains boolean semantics. Point 3, mostly cool.
>
>Bit twiddling and optimization are important to systems programmers. D is intended to cater to that audience. Point 4, cool.
>
>-------------------------------
>
>Additional Commentary:
>
>Please, let's not get hung up on what the underlying implementation should be; that's missing the point.
>
>Additionally, multiple **API-Level** definitions of what a boolean means should be avoided at all costs. That is, if you're writing a public API and you force users to apply your personal version of boolean (as method args, or whatever), then you're simply fracturing any possible resolution and confusing the hell out of potential users. In my humble opinion, that's an entirely selfish route to take. If you're going to be utterly selfless about sharing your code, why be utterly selfish about a clearly controversial issue at the same time?
>
>- Kris
>
>

Kris: "Right On The Mark!" :)

On Thu, 3 Jun 2004 20:34:55 +0000 (UTC), David L. Davis <SpottedTiger@yahoo.com> wrote:
> In article <c9nqcd$f21$1@digitaldaemon.com>, Kris says...
>>
>> 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We
>> really shouldn't care how they are represented internally. Walter can do
>> with it what he likes within the compiler. It's certainly syntactically
>> cleaner to use true and false, regardless of what they represent under the
>> hood.
>>
>> 2) Boolean should not be assigned a value other than another boolean; from
>> another variable or from an expression. Straying from this rule should
>> produce a compile-time error.
>>
>> 3) Boolean implementation should, where it makes a difference, strive for
>> performance. This relates to both execution time and to memory usage. That
>> is, if it's more efficient to implement a single boolean variable as a
>> byte/int/float/class/whatever (under the covers), then let the compiler get
>> on and do its thing. If, however, memory constraints are the primary factor
>> then the compiler should at least provide a mechanism for the programmer to
>> choose such a representation; the boolean[] is potentially an example. Those
>> who argue that there's never a need (nowadays) to pack data into its
>> smallest representable space simply have not /yet/ had the need to do so
>> (it's the "640KB ought to be enough for anyone" argument taken to the 640MB
>> level).
>>
>> 4) The usage of a boolean value as an arithmetic expression *RValue* has
>> been around since almost the dawn of programming. It's convenient (and
>> optimal) in many cases, though some might find the syntax uncomfortable.
>> It's the kind of thing that comes in handy when bit-twiddling, or trying to
>> eke out that last bit of whatever. One does not have to use it.
>>
>> ---------------------------
>>
>> Given that; Walter's choice of a bit to represent boolean values is a fair
>> one. After all, you only get two values for a bit value, right? Point 1,
>> totally cool.
>>
>> D bit variables can *currently* be assigned values other than true or false.
>> This should be viewed as a bug, and nothing more. Point 2, way bogus.
>>
>> As it stands, the bit implementation does indeed strive for performance when
>> used standalone. In fact, it uses a byte. When bit is used as an array, the
>> compiler switches strategies and packs them into the tightest space it can.
>> This is fine for many cases, but it /might/ be better if it were programmer
>> controllable. For example: I may wish to have a fast array of boolean
>> values. Currently I'd personally implement this as a byte[], but then I've
>> sacrificed some of the semantic notion of a boolean type. That's my choice,
>> and one I rather the compiler helped me out with. On the other hand, a
>> packed bit[] is a godsend for many, and it maintains boolean semantics.
>> Point 3, mostly cool.
>>
>> Bit twiddling and optimization are important to systems programmers. D is
>> intended to cater to that audience. Point 4, cool.
>>
>> -------------------------------
>>
>> Additional Commentary:
>>
>> Please, let's not get hung up on what the underlying implementation should
>> be; that's missing the point.
>>
>> Additionally, multiple **API-Level** definitions of what a boolean means
>> should be avoided at all costs. That is, if you're writing a public API and
>> you force users to apply your personal version of boolean (as method args,
>> or whatever), then you're simply fracturing any possible resolution and
>> confusing the hell out of potential users. In my humble opinion, that's an
>> entirely selfish route to take. If you're going to be utterly selfless about
>> sharing your code, why be utterly selfish about a clearly controversial
>> issue at the same time?
>>
>> - Kris
>>
>>
>
> Kris: "Right On The Mark!" :)

Kris: "Hear! Hear!" :)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Kris" <someidiot@earthlink.dot.dot.dot.net> escribió en el mensaje
news:c9nqcd$f21$1@digitaldaemon.com
| 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false.
We
| really shouldn't care how they are represented internally. Walter can do
| with it what he likes within the compiler. It's certainly syntactically
| cleaner to use true and false, regardless of what they represent under the
| hood.
|
| ...
|
| - Kris

Just a thought:
I remember that a couple of times ranges were requested. Something like
Pascal/Delphi's:

type my_range = (0..100);

(if I'm not mistaken). Why not finally implement this (with the best syntax
Walter/we can come up with) and define bool as:

range (false..true) bool;

Then bool would finally not accept anything different than false/true, and
each compiler would optimize it any way it wants (I really don't know about
this. Compilers are not something that I know much about) so efficiency
would be ok, I think. Maybe other advantages, and disadvantages for sure
(though I fail to see them).
Again, just a thought. Maybe we could kill two birds with one shot with
this.

-----------------------
Carlos Santander Bernal

I certainly wouldn't object to a packed (bit or bit array) boolean type, so maybe more than one boolean type would be OK.  Makes sense to me.  But please, please keep statements with boolean expressions both simple and type-safe.

I just came into this and I'm not sure I have totally digested all the conversation, but I have just one other request.  Please, I hope all boolean names are obvious.  I would be most upset by a boolean type called "red", "george", or "bit".  :-)

I hope I've merely misunderstood the current and planned status of boolean types, and that my pleas are superfluous.

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c9nqcd$f21$1@digitaldaemon.com...
> 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We really shouldn't care how they are represented internally. Walter can do with it what he likes within the compiler. It's certainly syntactically cleaner to use true and false, regardless of what they represent under the hood.

Well, this is a newsgroup that, in part, is about how we will implement the new language D. If you think we should not be looking into how things are implemented, you're in the wrong NG. Or maybe it's time for yet another group D.users?

> 2) Boolean should not be assigned a value other than another boolean; from another variable or from an expression. Straying from this rule should produce a compile-time error.

Absolutely correct. As I've said several times, this is the more important of the two issues - size being the other - but it's also the one that I think we're least likely to shake Walter on.

> 3) Boolean implementation should, where it makes a difference, strive for performance. This relates to both execution time and to memory usage. That is, if it's more efficient to implement a single boolean variable as a byte/int/float/class/whatever (under the covers), then let the compiler get on and do its thing. If, however, memory constraints are the primary factor then the compiler should at least provide a mechanism for the programmer to choose such a representation; the boolean[] is potentially an example. Those who argue that there's never a need (nowadays) to pack data into its smallest representable space simply have not /yet/ had the need to do so (it's the "640KB ought to be enough for anyone" argument taken to the 640MB level).

I said in this about two months ago. Best of luck getting any more interest than I got. ;/

> 4) The usage of a boolean value as an arithmetic expression *RValue* has been around since almost the dawn of programming. It's convenient (and optimal) in many cases, though some might find the syntax uncomfortable. It's the kind of thing that comes in handy when bit-twiddling, or trying to eke out that last bit of whatever. One does not have to use it.

If I understand you correctly, you're arguing that we should be able to use a boolean variable in an integral expression. If that's the case, you are contradicting point 2)

Please confirm/deny.


> ---------------------------
>
> Given that; Walter's choice of a bit to represent boolean values is a fair one. After all, you only get two values for a bit value, right? Point 1, totally cool.

Arguable, but I'll go with you. :-)

> D bit variables can *currently* be assigned values other than true or false. This should be viewed as a bug, and nothing more. Point 2, way bogus.

Correct. Big bogus.

> As it stands, the bit implementation does indeed strive for performance when used standalone. In fact, it uses a byte. When bit is used as an array, the compiler switches strategies and packs them into the tightest space it can. This is fine for many cases, but it /might/ be better if it were programmer controllable. For example: I may wish to have a fast array of boolean values. Currently I'd personally implement this as a byte[], but then I've sacrificed some of the semantic notion of a boolean type. That's my choice, and one I rather the compiler helped me out with. On the other hand, a packed bit[] is a godsend for many, and it maintains boolean semantics. Point 3, mostly cool.

How do you like this for efficient:

  bool b = null !== p;

? The compiler has to do something like (p != 0xfffffff) ? 1 : 0.

I don't call that optimal. If bool is the size of the architecture, say 32-bits, then the compiler can translate every boolean expression into that size, and every test can be a single one, i.e. without the need to translate into 1 or 0. Things are either 0 (or 0x00000000) or !0 (0x00000001 => 0xFFFFFFFF). It doesn't matter, and it's as fast as is possible to be.

> Bit twiddling and optimization are important to systems programmers. D is intended to cater to that audience. Point 4, cool.

They are. But if bit and bool are separate things then Point 4 is cool. As it stands 4) violates 2), so this reasoning is flawed.

> -------------------------------
>
> Additional Commentary:
>
> Please, let's not get hung up on what the underlying implementation should be; that's missing the point.

Again, this is a NG for the design and implementation of D. What, then, is inappropriate about our discussing this, or any other, implementation issue?

> Additionally, multiple **API-Level** definitions of what a boolean means should be avoided at all costs. That is, if you're writing a public API and you force users to apply your personal version of boolean (as method args, or whatever), then you're simply fracturing any possible resolution and confusing the hell out of potential users. In my humble opinion, that's an entirely selfish route to take. If you're going to be utterly selfless about sharing your code, why be utterly selfish about a clearly controversial issue at the same time?

Well, I kind of agree, and I kind of don't. I see the current bool definition as flawed, and potentially buggy. While it's certainly easier to go along with Walter's vision of bool, you can't exactly say that doing would be an unequivocal kindness to my users. If I supply something that's easier to use, but more prone to misuse, is that really being selfless? If I require them to add a couple of casts here and there in order to do something bad, is that selfish?

Yet again, and for the last 2 years, I sigh at the apparent preference for ease of coding over maintenance and robustness concerns. Pretty much every master of this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, Hunt & Thomas, Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again that maintenance/debugging/refactoring costs dwarf the initial coding cost. So leaving a language, or its libraries, open to more errors than necessary for the sake of some dinky little trick / saving a line of code could be said to be ... <searching for as inoffensive word as possible> ... wrong.

Or maybe it's just me, and I shouldn't want D to address the abject, and multi-billion-dollar wasteful, failures of other languages, and end up being a roaring success. Let's just have it as a partial, buggy, semi-cool thing for hobbyists and people who want to spend their time in debuggers. :(

> I certainly wouldn't object to a packed (bit or bit array) boolean type, so maybe more than one boolean type would be OK.  Makes sense to me.  But please, please keep statements with boolean expressions both simple and type-safe.

Not sure. My belief is that if the only way to achieve the desired aims of bool is to disallow arrays of them, and provide another - either library or language - construct for arrays, then it's worth it. But this would be a compromise, and could not be described otherwise.

> I just came into this and I'm not sure I have totally digested all the conversation, but I have just one other request.  Please, I hope all boolean names are obvious.  I would be most upset by a boolean type called "red", "george", or "bit".  :-)

Spot on.

> I hope I've merely misunderstood the current and planned status of boolean types, and that my pleas are superfluous.

You haven't. They're not. But they are probably wasted, and you and I should be saving our keystrokes. :(

Carlos wrote:
>range (false..true) bool;

I'm not sure I'm qualified to judge about implementation, but it looks like a great idea and passes the user test with me.


I'm not trying to request another feature, but D users might also like something like this:

boolean goodChoice;
int consequence[goodChoice];
or
int consequence[boolean];

This is translated Pascal, but you get the idea.

Hey Matthew,

The title says it all, but since you asked for clarification:

"Matthew"  wrote
> If I understand you correctly, you're arguing that we should be able to
use a
> boolean variable in an integral expression. If that's the case, you are contradicting point 2)
>
> Please confirm/deny.

My statement tried to be clear about this usage as an arithmetic RValue, rather than an LValue. An LValue is the target of an assignment, whereas an RValue is typically anything on the right-hand side of the '='. This doesn't contradict point 2, which is talking about the bool strictly as an LValue.

BTW I'm not as you say, arguing point 4 per se. I'm just pointing out its history and usage. I am personally comfortable with the boolean RValue style syntax, but wouldn't cry out if it were not supported. In other words, this point is of relatively low value. I hope this clarifies suitably?


> Well, this is a newsgroup that, in part, is about how we will implement
the new
> language D. If you think we should not be looking into how things are implemented, you're in the wrong NG. Or maybe it's time for yet another
group
> D.users?

Perhaps you are in the wrong newsgroup, good Dr ... I would put it to you that the majority of users on the NG are exactly that. Users. I mean, discussing the language usage, features, limitations, restrictions, or new ideas are often quite a world apart from the actual underlying compiler implementation issues. This, you already know. Part of the problem in combining the two is that it causes unnecessary worry and thrashing within the overall group.

Might you consider another group called D.internals, or D.implementation.all.in.mud.wrestling, instead? Yes ~ you've already stated how thick your skin is, so permit me some latitude here please <g>

Regards;

On Fri, 4 Jun 2004 10:16:49 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message
> news:c9nqcd$f21$1@digitaldaemon.com...
>> 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We
>> really shouldn't care how they are represented internally. Walter can do
>> with it what he likes within the compiler. It's certainly syntactically
>> cleaner to use true and false, regardless of what they represent under the
>> hood.
>
> Well, this is a newsgroup that, in part, is about how we will implement the new
> language D. If you think we should not be looking into how things are
> implemented, you're in the wrong NG. Or maybe it's time for yet another group
> D.users?

What Kris was trying to say (correct me if I am wrong) was that we should concentrate on how bool looks to the programmer not how it is done. Or rather that in this thread that is what he wants to do, start another thread on the implementation but just concentrate on looks here.

>> 2) Boolean should not be assigned a value other than another boolean; from
>> another variable or from an expression. Straying from this rule should
>> produce a compile-time error.
>
> Absolutely correct. As I've said several times, this is the more important of the
> two issues - size being the other - but it's also the one that I think we're
> least likely to shake Walter on.
>
>> 3) Boolean implementation should, where it makes a difference, strive for
>> performance. This relates to both execution time and to memory usage. That
>> is, if it's more efficient to implement a single boolean variable as a
>> byte/int/float/class/whatever (under the covers), then let the compiler get
>> on and do its thing. If, however, memory constraints are the primary factor
>> then the compiler should at least provide a mechanism for the programmer to
>> choose such a representation; the boolean[] is potentially an example. Those
>> who argue that there's never a need (nowadays) to pack data into its
>> smallest representable space simply have not /yet/ had the need to do so
>> (it's the "640KB ought to be enough for anyone" argument taken to the 640MB
>> level).
>
> I said in this about two months ago. Best of luck getting any more interest than
> I got. ;/

This could be the difference between a 'bool' and a 'bit'. eg 'bit' is packed and 'bool' is not. It would of course require the creation of a 'bool' type and the removal of the alias of bit.

>> 4) The usage of a boolean value as an arithmetic expression *RValue* has
>> been around since almost the dawn of programming. It's convenient (and
>> optimal) in many cases, though some might find the syntax uncomfortable.
>> It's the kind of thing that comes in handy when bit-twiddling, or trying to
>> eke out that last bit of whatever. One does not have to use it.
>
> If I understand you correctly, you're arguing that we should be able to use a
> boolean variable in an integral expression. If that's the case, you are
> contradicting point 2)
>
> Please confirm/deny.

It was my impression that Kris is saying in #2 that we shouldn't be able to assign to a bool something that is not bool, in other words if a bool is the lvalue you must have a bool as the rvalue.

Here he's saying that implicit conversion from bool to other integral types is often used and should stay.

(pls correct me if I am wrong Kris)

>> ---------------------------
>>
>> Given that; Walter's choice of a bit to represent boolean values is a fair
>> one. After all, you only get two values for a bit value, right? Point 1,
>> totally cool.
>
> Arguable, but I'll go with you. :-)
>
>> D bit variables can *currently* be assigned values other than true or false.
>> This should be viewed as a bug, and nothing more. Point 2, way bogus.
>
> Correct. Big bogus.
>
>> As it stands, the bit implementation does indeed strive for performance when
>> used standalone. In fact, it uses a byte. When bit is used as an array, the
>> compiler switches strategies and packs them into the tightest space it can.
>> This is fine for many cases, but it /might/ be better if it were programmer
>> controllable. For example: I may wish to have a fast array of boolean
>> values. Currently I'd personally implement this as a byte[], but then I've
>> sacrificed some of the semantic notion of a boolean type. That's my choice,
>> and one I rather the compiler helped me out with. On the other hand, a
>> packed bit[] is a godsend for many, and it maintains boolean semantics.
>> Point 3, mostly cool.
>
> How do you like this for efficient:
>
>   bool b = null !== p;
>
> ? The compiler has to do something like (p != 0xfffffff) ? 1 : 0.
>
> I don't call that optimal. If bool is the size of the architecture, say 32-bits,
> then the compiler can translate every boolean expression into that size, and
> every test can be a single one, i.e. without the need to translate into 1 or 0.
> Things are either 0 (or 0x00000000) or !0 (0x00000001 => 0xFFFFFFFF). It doesn't
> matter, and it's as fast as is possible to be.

I can't comment here. This is implementation I think we should start by deciding how it should look and act before we decide how it is implemented.

>> Bit twiddling and optimization are important to systems programmers. D is
>> intended to cater to that audience. Point 4, cool.
>
> They are. But if bit and bool are separate things then Point 4 is cool. As it
> stands 4) violates 2), so this reasoning is flawed.

I don't think 4) violates 2) (see my reasoning above)

>> -------------------------------
>>
>> Additional Commentary:
>>
>> Please, let's not get hung up on what the underlying implementation should
>> be; that's missing the point.
>
> Again, this is a NG for the design and implementation of D. What, then, is
> inappropriate about our discussing this, or any other, implementation issue?

Sure, but do it in another thread, i.e. one thread for how bool looks and acts and one for the implementation. Lets get one out of the way before moving on to the other.

>> Additionally, multiple **API-Level** definitions of what a boolean means
>> should be avoided at all costs. That is, if you're writing a public API and
>> you force users to apply your personal version of boolean (as method args,
>> or whatever), then you're simply fracturing any possible resolution and
>> confusing the hell out of potential users. In my humble opinion, that's an
>> entirely selfish route to take. If you're going to be utterly selfless about
>> sharing your code, why be utterly selfish about a clearly controversial
>> issue at the same time?
>
> Well, I kind of agree, and I kind of don't. I see the current bool definition as
> flawed, and potentially buggy.

I am having a hard time thinking of a possible bug someone might write. Lets assume 2) above is changed, can you give me an example of where using a bool as an rvalue as in Walters previous examples causes a bug not caught by the compiler.

> While it's certainly easier to go along with
> Walter's vision of bool, you can't exactly say that doing would be an unequivocal
> kindness to my users. If I supply something that's easier to use, but more prone
> to misuse, is that really being selfless? If I require them to add a couple of
> casts here and there in order to do something bad, is that selfish?

http://www.datanation.com/fallacies/ap.htm
(please don't take offence)

> Yet again, and for the last 2 years, I sigh at the apparent preference for ease
> of coding over maintenance and robustness concerns. Pretty much every master of
> this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, Hunt & Thomas,
> Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again that
> maintenance/debugging/refactoring costs dwarf the initial coding cost. So leaving
> a language, or its libraries, open to more errors than necessary for the sake of
> some dinky little trick / saving a line of code could be said to be ...
> <searching for as inoffensive word as possible> ... wrong.

Being a C programmer I am probably biased, I have seen Walters examples, I think they are clearer than the others proposed. If it is well known that bool is implicitly castable to int and has a value of 0 or 1 then I cannot see the problem.

It doesn't stop you from coding the casts to make your code 'clearer' regardless of whether the compiler requires it.

> Or maybe it's just me, and I shouldn't want D to address the abject, and
> multi-billion-dollar wasteful, failures of other languages, and end up being a
> roaring success. Let's just have it as a partial, buggy, semi-cool thing for
> hobbyists and people who want to spend their time in debuggers. :(

http://www.datanation.com/fallacies/conseq.htm
(please don't take offence)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/