> Bool's particular behavior just doesn't have the leverage to make much of any difference in real programs. On_scope is far more interesting, because for a certain class of programming problems it can have a dramatic effect on improving them.

That's actually the best point so far. I agree.

L.

Walter Bright wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:14g4upyin8106$.uuzir980l0jb.dlg@40tude.net...
>> Agreed that the 'while(1)' idiom is not going anywhere, but Walter, which
>> would *you* write using D nowadays?
>>
>>  while(1) ...
>>
>> or
>>
>>  while(true) ...
>>
>> And why would you choose one form over the other?
> 
> They are both equivalent. There is no technical, usability, portability, efficiency, or aesthetic advantage to one form over the other. I'd likely use the former simply out of habit and because it is shorter. As far as I'm 

As for the usability/aesthetic advantage, it's arguable that there's no difference. I prefer the 'true' version, as I find it more expressive, even if the difference is not that big and while(1) doesn't bother me that much.

> concerned, arguing about it is like arguing over if the { goes on the same line or the next :-)
> 
Which although not a critical issue, still has some some things that could be said about it. :D

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Walter Bright wrote:
> "Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message 
>> The problem in all these bool wars so far is I never saw an argument that would be against true booleans (while(BooleanExpression) and all that...).
>> The arguments like:
>> while(true) is much much bigger than while(1) or
>> while(a)    is much smaller and more understandable than while(a>0)
>> //hm while(a) is actually while(a!=0) but did I really mean a>0?)
>> and like that don't really count.
>>
>> Adding true booleans makes no code break, only adds compiler errors that make  a coder think more about what he is doing and require awfull changes from if(b) to if(b!=0) and stop him from doing things like adding two bools or adding an int to a bool.
> 
> Like I said, I never looked back with nostalgia upon Pascal after using C <g>. I know many people think the wordier versions are more readable. I don't. I'm also very reluctant to abandon things that may have contributed to C being wildly popular and burying Pascal in an unmarked grave out in the desert.
> 

Thinking about that (the Pascal verbosity), I find that in most cases I agree that wordier versions are less readable, however, that is only *usually*, not in all situations. It really has to be considered on an individual case, not on a general basis.
For instance, I abhor the BEGIN/END construct, so much that I immediately distrust any language with it (yes Ruby, that means you..). I also find stuff like VAR and THEN annoying, but in the case of '1' vs 'true', I prefer 'true'.
We can't go completely against the way of wordiness, because that would be the road to obfuscation. Do not generalize, look at each case appropriately. And harmony is the key.



-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Walter Bright escribió:
> 
> One should be very careful about stepping away from C's implicit promotion rules for a language that aims to be a successor to C. C absolutely *buried* Pascal.
> 
> Pascal didn't have implicit type conversions. That meant that typical Pascal code was littered with casts. It was ugly, and I'd argue that casting reduces type safety, rather than enhancing it.
> 
> Pascal played catchup ever since, adopting features of C. Then Pascal++ (i.e. Modula 2) came out, which was promptly buried by C++. 
> 
> 

That depends on how you code and what you code. I recently wrote a 1600+ LOC Pascal program and I never used a single cast, just because I never needed one. So, that argument is not very strong because it depends on the nature of each situation.

-- 
Carlos Santander Bernal

In article <du187e$14bk$4@digitaldaemon.com>, Walter Bright says...
>"Derek Parnell" <derek@psych.ward> wrote in message
>> [snip]

>As far as I'm concerned, arguing about it is like arguing over if the { goes on the same line or the next :-)

No no no, excuse me, nobody argues that because everybody knows that '{' and '}' goes in the next line, NEVER IN THE SAME!! :P

Sorry, I couldn't resist! :D

Tom;

Walter Bright wrote:
> 
> What I especially think is bad style, however, are things like:
> 
>     const int forever = 1;
>     ...
>     while (forever) ...
> 
> I don't see them too often, but it does happen. 

It perhaps sidesteps the issue, but I use "for(;;)" in these cases, mostly because it avoids a constant conditional warning in VC++ :-p "while(true)" is probably a bit more meaningful however as it's not a counting loop.


Sean

Sean Kelly wrote:
> It perhaps sidesteps the issue, but I use "for(;;)" in these cases, mostly because it avoids a constant conditional warning in VC++ :-p "while(true)" is probably a bit more meaningful however as it's not a counting loop.

I use that as well. It even defeats the "while (1) is shorter" argument by being one character shorter. <g>

On Wed, 01 Mar 2006 04:23:00 +1100, Sean Kelly <sean@f4.ca> wrote:

> Walter Bright wrote:
>>  What I especially think is bad style, however, are things like:
>>      const int forever = 1;
>>     ...
>>     while (forever) ...
>>  I don't see them too often, but it does happen.
>
> It perhaps sidesteps the issue, but I use "for(;;)" in these cases, mostly because it avoids a constant conditional warning in VC++ :-p "while(true)" is probably a bit more meaningful however as it's not a counting loop.

And I remember somebody writing ..

  #define forever for(;;)

  . . .

  forever{
      . . .
     }

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:

> And I remember somebody writing ..
> 
>   #define forever for(;;)
> 
>   . . .
> 
>   forever{
>       . . .
>      }

I'm pretty sure that I saw a :

#define EVER ;;

As in: for (EVER) { young() }

--anders

Anders F Björklund wrote:
> Derek Parnell wrote:
> 
>> And I remember somebody writing ..
>>
>>   #define forever for(;;)
>>
>>   . . .
>>
>>   forever{
>>       . . .
>>      }
> 
> I'm pretty sure that I saw a :
> 
> #define EVER ;;
> 
> As in: for (EVER) { young() }

LOL


Sean