C++ has this and it makes code little more readable in certain cases:

if(something() or foo() and bar()){  ... }

instead of this in D:

if(something() || foo() && bar()){ ... }


possible enhancement request?  or is there a good reason it is not in the language?

Caligo:

> possible enhancement request?  or is there a good reason it is not in the language?

I have asked for them, but Walter doesn't want, he thinks C/C++ programmers will not use them... :-( Despite D != C/C++.

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

Jonathan M Davis:

> And I'm actually mildly shocked that anyone (at least any programmer) would think that "or" and "and" were more readable. The fact that operators aren't words is a _major_ boon to code readibility.

This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND".

"or" and "and" are about as long as those symbols in char count, quicker to write because they are lowercase letters instead of symbols, and they are much simpler told apart from bitwise & |. This avoids some bugs where people use "&&" where they want to use "&" or the other way around. Such bugs are so common that D have had to introduce one or two rules to help avoid them.

Python got this waaaaay much better than D. Using "&" for (uncommon, in Python) binary ops, and "and" for the common logic boolean operation.

Bye,
bearophile

On Thursday, February 16, 2012 23:53:34 bearophile wrote:
> > And I'm actually mildly shocked that anyone (at least any programmer)
> > would
> > think that "or" and "and" were more readable. The fact that operators
> > aren't words is a _major_ boon to code readibility.
> 
> This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND".
> 
> "or" and "and" are about as long as those symbols in char count, quicker to write because they are lowercase letters instead of symbols, and they are much simpler told apart from bitwise & |. This avoids some bugs where people use "&&" where they want to use "&" or the other way around. Such bugs are so common that D have had to introduce one or two rules to help avoid them.
> 
> Python got this waaaaay much better than D. Using "&" for (uncommon, in Python) binary ops, and "and" for the common logic boolean operation.

Seriously? && and || are _way_ more readible, because they're obviously not functions or variables. It's immediately obvious what the operators are when scanning code. That's not the case when the operators are words instead of symbols. I'm certain that you'd have quite a few programmers up in arms if you tried to change && to "and" and || to "or." And having multiple operators which do exactly the same thing is a horrible idea which reduces code readibility. So, even adding them as alternate options is a really bad idea IMHO.

I'm surprised that anyone would think that and was better than &&.

- Jonathan M Davis

On 02/17/2012 05:53 AM, bearophile wrote:
> Caligo:
>
>> possible enhancement request?  or is there a good reason it is not in
>> the language?
>
> I have asked for them, but Walter doesn't want, he thinks C/C++ programmers will not use them... :-( Despite D != C/C++.
>
> ----------------
>
> Jonathan M Davis:
>
>> And I'm actually mildly shocked that anyone (at least any programmer) would
>> think that "or" and "and" were more readable. The fact that operators aren't
>> words is a _major_ boon to code readibility.
>
> This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND".
>

In what way is '&&' meaningless or unrelated to 'AND' ?

> "or" and "and" are about as long as those symbols in char count, quicker to write because they are lowercase letters instead of symbols,

Valid point.

> and they are much simpler told apart from bitwise&  |. This avoids some bugs where people use "&&" where they want to use"&" or the other way around. Such bugs are so common that D have had to introduce one or two rules to help avoid them.
>

&& and & don't look the same to me. Furthermore, I have never run into any parser special cases except if(x=y()) and x | b<c, and then the error messages were actually annoying and meaningless.

> Python got this waaaaay much better than D. Using "&" for (uncommon, in Python) binary ops, and "and" for the common logic boolean operation.
>
> Bye,
> bearophile

Python also uses "&" for set intersection afaik.

On 02/17/2012 06:02 AM, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 23:53:34 bearophile wrote:
>>> And I'm actually mildly shocked that anyone (at least any programmer)
>>> would
>>> think that "or" and "and" were more readable. The fact that operators
>>> aren't words is a _major_ boon to code readibility.
>>
>> This is very very wrong. Of course that "or" and "and" are more readable.
>> When you read "and" it's immediate to think it's probably related to the
>> AND logical or binary operation more than meaningless symbols that are
>> unrelated to "AND".
>>
>> "or" and "and" are about as long as those symbols in char count, quicker to
>> write because they are lowercase letters instead of symbols, and they are
>> much simpler told apart from bitwise&  |. This avoids some bugs where
>> people use "&&" where they want to use"&" or the other way around. Such
>> bugs are so common that D have had to introduce one or two rules to help
>> avoid them.
>>
>> Python got this waaaaay much better than D. Using "&" for (uncommon, in
>> Python) binary ops, and "and" for the common logic boolean operation.
>
> Seriously?&&  and || are _way_ more readible, because they're obviously not
> functions or variables.  It's immediately obvious what the operators are when
> scanning code. That's not the case when the operators are words instead of
> symbols. I'm certain that you'd have quite a few programmers up in arms if you
> tried to change&&  to "and" and || to "or." And having multiple operators
> which do exactly the same thing is a horrible idea which reduces code
> readibility. So, even adding them as alternate options is a really bad idea
> IMHO.
>
> I'm surprised that anyone would think that and was better than&&.
>
> - Jonathan M Davis

The editor would highlight the keywords, so you definitely would not confuse them for variables. This is already true for 'is' and 'in'.
I don't need any alternative operators though, I'd rather introduce some new ones, like the implication operator '==>'.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.450.1329455016.20196.digitalmars-d@puremagic.com...
>
> Seriously? && and || are _way_ more readible, because they're obviously
> not
> functions or variables. It's immediately obvious what the operators are
> when
> scanning code. That's not the case when the operators are words instead of
> symbols. I'm certain that you'd have quite a few programmers up in arms if
> you
> tried to change && to "and" and || to "or." And having multiple operators
> which do exactly the same thing is a horrible idea which reduces code
> readibility. So, even adding them as alternate options is a really bad
> idea
> IMHO.
>
> I'm surprised that anyone would think that and was better than &&.
>

This is why I think people are nuts when they claim that english-like VB-style syntax is more readable than C-style.

(Yea, to a grandmother with zero programming experience english-like languages are more readable. For a programmer it's worse becase code != english.)

I would use them over '||' and '&&' for the reasons bearophile gave. Highlighted as keywords, they're easily set appart, easier to type, and more distinguished... then again if I had my way I'd remove the '('/')' brackets, ending marks, and auto keyword; switched the definition name-type placement and change if/else/return/contract syntax...

    foo( a, b: float ): int
    {
        contract in
        {
            assert( a != 0 and b != 0 )
        }

        result: = a + b

        case a >= b { ret result }
        else b > a { ret a }

        ret 0
    }

    writeLine: alias writeln

    main()
    {
        a, b: float = 10.2, 5.0

        writeLine( foo( a, b ) )
    }

Tell me that's not beautiful code! :D

On Thu, Feb 16, 2012 at 11:16 PM, Nick Sabalausky <a@a.a> wrote:
>
> This is why I think people are nuts when they claim that english-like VB-style syntax is more readable than C-style.
>
> (Yea, to a grandmother with zero programming experience english-like languages are more readable. For a programmer it's worse becase code != english.)
>
>

This is not about having an English-like syntax.  Not every programmer speaks English, but nearly every programming language uses English words.  At least for them 'and'  and && are about the same.

I can agree that having multiple operators that do the exact same thing can be problematic, so such a change might be too late for D (unless we replace &&, ||, etc. with 'and', 'or', etc.).  But at the same time, when I was new to D I found things like 'is' and '==' confusing, and I'm sure I'm not the only one.

Another thing, most editors render keywords with a different colour than, say, the logical operators. So in

if(a or b and c){ }

the 'if', 'and', and 'or' are the same colour.

On Friday, February 17, 2012 06:47:20 F i L wrote:
> I would use them over '||' and '&&' for the reasons bearophile gave. Highlighted as keywords, they're easily set appart, easier to type, and more distinguished... then again if I had my way I'd remove the '('/')' brackets, ending marks, and auto keyword; switched the definition name-type placement and change if/else/return/contract syntax...
> 
>      foo( a, b: float ): int
>      {
>          contract in
>          {
>              assert( a != 0 and b != 0 )
>          }
> 
>          result: = a + b
> 
>          case a >= b { ret result }
>          else b > a { ret a }
> 
>          ret 0
>      }
> 
>      writeLine: alias writeln
> 
>      main()
>      {
>          a, b: float = 10.2, 5.0
> 
>          writeLine( foo( a, b ) )
>      }
> 
> Tell me that's not beautiful code! :D

It's not beautiful code.

- Jonathan M Davis

On Friday, 17 February 2012 at 05:53:08 UTC, Jonathan M Davis wrote:
> On Friday, February 17, 2012 06:47:20 F i L wrote:
>> I would use them over '||' and '&&' for the reasons bearophile
>> gave. Highlighted as keywords, they're easily set appart, easier
>> to type, and more distinguished... then again if I had my way I'd
>> remove the '('/')' brackets, ending marks, and auto keyword;
>> switched the definition name-type placement and change
>> if/else/return/contract syntax...
>> 
>>      foo( a, b: float ): int
>>      {
>>          contract in
>>          {
>>              assert( a != 0 and b != 0 )
>>          }
>> 
>>          result: = a + b
>> 
>>          case a >= b { ret result }
>>          else b > a { ret a }
>> 
>>          ret 0
>>      }
>> 
>>      writeLine: alias writeln
>> 
>>      main()
>>      {
>>          a, b: float = 10.2, 5.0
>> 
>>          writeLine( foo( a, b ) )
>>      }
>> 
>> Tell me that's not beautiful code! :D
>
> It's not beautiful code.
>
> - Jonathan M Davis

I knew someone was going to say that >:{