Kevin Bealer wrote:

>In article <c9bssf$1mld$1@digitaldaemon.com>, Arcane Jill says...
>  
>
>>In article <c9blde$1bs0$3@digitaldaemon.com>, Walter says...
>>
>>    
>>
>>>There are two different things going on here - one is evaluation order, and
>>>the other is the operator precedence, associativity and commutativity rules.
>>>The latter are well defined, in D as well as C++,
>>>      
>>>
>>Is precedence order defined the same way in D that it is in C?
>>
>>I ask because I think C got it wrong, and I'd hate to think we were copying the
>>flaws as well as the good bits.
>>
>>I always thought it a mistake that the precedence of &, | and ^ was defined such
>>that:
>>
>>    
>>
>>>      if (a & 1 == 1)
>>>      
>>>
>>gives (1 == 1) precedence over (a & 1). It's not intuitive in C. C++ copied it,
>>and it's not intuitive in C++. I think even Java copied it, and it's not
>>intuitive there either. Believe it or not, I think BASIC got this right!
>>
>>I would prefer precedence order to be:
>>
>><< >>
>>& ^ |
>>* / %
>>+ -
>>< > <= >= etc
>>== !=
>>&& ||
>>
>>(but I guess it would break too much to change that now).
>>
>>Arcane Jill
>>    
>>
>
>I remember that "*" is before "+", comparisons (<, ==) are before "&&" and "||",
>and maybe one or two others.  For almost everything else I use the parens, for
>readability and safety.  I don't expect the compiler to get it wrong, but I know
>that I will, and I hate debugging this stuff: I'd rather be hunting orc than
>squirrel if you get my meaning.
>
>Incidentally, what are "&&" and "||" supposed to return?  I think at one point I
>read that || returns the first argument that is true, or the second argument,
>but I tried it and it didn't work in whatever language I was using.  It would be
>useful if you could say: (return x || y || 100), but I don't know if that makes
>sense in the bigger picture.
>
>Kevin
>  
>

You mean?

return (x || y || 100);


Which logically will always return true because anything other then zero = true;

-- 
-Anderson: http://badmama.com.au/~anderson/

>JavaScript does that with ||, like alert("foo" || "bar"); displays "foo". I've never used it in real code, but it is interesting. C style languages just return 0 for false and 1 for true; which is depended on in some cases. Changing it would cause those "subtle bugs" I would think.

Don't they return true or false?

>Since D is designed to appeal to C/C++ programmers, changing the precedence order that, for good or ill, we're all used to would introduce subtle bugs. I'd prefer to change only things that would yield obvious errors if done using the C/C++ semantics.

D would appeal more to _this_ C programmer if _all_ the flaws of C/C++ were fixed. On the other hand, I believe that the last time this particular concern was raised, Walter was able to convince me that this was the _correct_ order. However, I seem to recall that my agreement required that boolean not be implicitly cast to or from other types.

"Juan C" <Juan_member@pathlink.com> wrote in message news:c9ctl4$sg$1@digitaldaemon.com...
> D would appeal more to _this_ C programmer if _all_ the flaws of C/C++
were
> fixed.

The trouble with that is there is little agreement on what _all_ the flaws are!

In article <c9cpc5$2si0$1@digitaldaemon.com>, Vathix says...
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c9c6uu$24ul$1@digitaldaemon.com...
>   ...
>> Incidentally, what are "&&" and "||" supposed to return?  I think at one
>point I
>> read that || returns the first argument that is true, or the second
>argument,
>> but I tried it and it didn't work in whatever language I was using.  It
>would be
>> useful if you could say: (return x || y || 100), but I don't know if that
>makes
>> sense in the bigger picture.
>>
>
>JavaScript does that with ||, like alert("foo" || "bar"); displays "foo". I've never used it in real code, but it is interesting. C style languages just return 0 for false and 1 for true; which is depended on in some cases. Changing it would cause those "subtle bugs" I would think.

The purpose of this, conceptually, is that there are a lot of times in C, at least, where you might like to do something like this:

void bar(int x, int y, char * optional_arg)
{
char * baz = optional_arg || getenv("BAR_BAZ") || "<default>";
..
}

Since C uses pointers for everything, and a non-null pointer is true, this allows you to pick the first "value source" that is non-null.  If you take advantage of this, you can program very readable code: a sequence of "||", read as "or else try", is very understandable compared to an if-then-else pile.

It shouldn't hurt semantics either: work out the above and you can see that if "baz" is tested as a boolean, taking the first "nonzero" value, or the last value in the chain (the second, in the 2-argument case) will work.

Maybe none of this is true in D.  I don't expect this would work in the presence of objects, since boolean bitmath and operator overloading probably clobber it. It's not a feature request, just wondered what I was remembering it from.

Kevin