`and` and `or` as alternatives to `&&` and `||`

[maxtoroq]

This would make programs easier to read.

Category: Boolean conditional logical operators

[HaloFour]

Do they provide any additional benefit beyond being easier to read specifically for people who aren't already familiar with the plethora of other languages that share the same Boolean operators? If not I don't see why it would be worth the effort. I wouldn't favor this any more than I would favor forcing VB.NET to accept && or || as alternatives to its Boolean operators.

[maxtoroq]

@HaloFour Not specifically for people who aren't already familiar with the plethora of other languages that share the same Boolean operators, it would make it easier for everyone, including experienced programmer. Syntax matters.

[HaloFour]

Consistent syntax matters even more. You learn it once and done. There is no reason to have two interchangable sets of operators. There is especially no reason given that C# has six Boolean operators, not two. What do you propose for the remainder?

[maxtoroq]

@HaloFour If that's your argument then why lambda expressions when you have delegate?

[HaloFour]

Lambda syntax supersedes anonymous delegates as being appreciably superior, familiar and succinct in selector delegates which are incredibly common in LINQ. You can only continue to use anonymous delegates as a relic of backward compatibility.

Your renaming of the operators provides no benefit, is more verbose and would only provide very temporary familiarity to people who are coming from a non-C/C++ language background. And there are still four other Boolean operators.

[maxtoroq]

@HaloFour Now you are just repeating yourself. Your point is made.

[alrz]

How many logical and or or do you have in your code? Definitely there is something wrong with that and you should solve this unreadability in some other ways. Anywho, && and || are more readable to me and they're consistent with corresponding bitwise kinds. I would save and or or for conjunctive and disjunctive patterns, they would make more sense in that context.

[maxtoroq]

@alrz I don't understand, why would there be anything wrong with my code?

Anywho, && and || are more readable to me

Then continue to use them. In what ways this new syntax affects you or the language in general?

[mburbea]

What about the bitwise & and | operators? Sadly, you'd probably have to introduce things like::

and for & or for | andalso for && orelse for ||

I personally think that I'd prefer to not do this.

[maxtoroq]

@mburbea That is not needed.

[mburbea]

Why? Says who? You're ignoring the fact that these operators offer short circuiting behavior.

var x = SomeBoolOp() || SomeOtherBoolOp();
var y = SomeBoolOp() | SomeOtherBoolOp();

x and y will have the same value, but the second line will evaluate the side effects of SomeOtherBoolOp, where as the first line will not. That's a pretty useful distinction and if we offer alternate syntax we should offer it for all variants.

I also question why just these two boolean logic operators? Why not just go full sql and change the unary negation operator with not?

[HaloFour]

@mburbea And don't forget xor. While we're at it, we should change the name of the compiler from csc.exe to vbc.exe.

[alrz]

Personally I would like to see complement operator, too. regarding readability and consistency.

[maxtoroq]

@mburbea I know the difference between && and &.

if we offer alternate syntax we should offer it for all variants.

Why?

Why not just go full sql and change the unary negation operator with not?

That's not a bad idea, but this issue is about and and or only.

[mburbea]

Ah yes good point, xor certainly should be allowed. :+1:

Well I'd think that complement might be the ~ operator. Where as not would be the equivalent of !.

What I'm trying to point out is your asking for making C# like vb, but you're not even thinking out these operators as well as the vb team. This would also cause massive confusion to Vb users who would have to remember the different meaning of and in C# vs vb.

[alrz]

By the way, I don't see any reason that why we can't use plus, division, multiply or minus operators. They are very readable.

[maxtoroq]

What I'm trying to point out is your asking for making C# like vb, but you're not even thinking out these operators as well as the vb team. This would also cause massive confusion to Vb users who would have to remember the different meaning of and in C# vs vb.

I had no idea VB had such a bad design. Should C# be constrained by the bad design of VB?

[mburbea]

Is it a bad design? Why is and obviously &&?

[maxtoroq]

@mburbea Having And and AndAlso is a terrible design. First, it's confusing. Second, it saves the best keyword (And) for the least used case. Short-circuit is by far the most used and needed behavior. I cannot remember the last time I used & or | for boolean purposes.

[alrz]

I cannot remember the last time I used & or | for boolean purposes.

Once I did use the = for boolean purposes e.g. var boolean_purposes = false;

[HaloFour]

@maxtoroq

First, it's confusing. Second, it saves the best keyword (And) for the least used case.

You assume that VB was designed initially 14 years ago and in a bubble. Despite the marketshare-destroying incompatibilities they did introduce it is still largely derived from a 45 year old language where AND already had a specific behavior, which did not include short-circuiting. Converting the existing binary AND keyword to a short-circuiting logical operator and introducing a new BITAND operator was not well received by the community during VB.NET beta 1.

@alrz

Once I did use the = for boolean purposes e.g. var boolean_purposes = false;

Clearly var boolean_purposes equals false; is much clearer. Actually, MOVE FALSE TO BOOLEAN-PURPOSES. is even clearer. I suggest that C# become COBOL.

[gafter]

I don't see how adding these to the language makes any existing programs easier to read. Are you saying that having two different ways of saying the same thing in the language makes programs easier to read, because it adds a bit of variety, thus making the reading experience more interesting? </sarcasm>

[gafter]

Perhaps you're suggesting we should add these to the language earlier rather than later, to make sure we cannot use them later to express conjunctive and disjuntive types and/or patterns. Or should that be types &/| patterns. </sarcasm>*

*I'm in a mood.

[gafter]

@alrz

By the way, I don't see any reason that why we can't use plus, division, multiply or minus

That's not consistent. Either it is plus, dividedBy, times, and minus, or add, divide, multiply, and subtract. I'm not sure which I like better.

[gafter]

Could it be andthen and orelse? I like Ada.

[alrz]

@gafter I like the more expressive version: if(a andofcourse b orpossibly c) {}

That's not consistent.

You're right, it should be multiplication, subtraction, addition and division to be consistent.

[aluanhaddad]

I don't think this is a good idea. There are enough operators. Also precedence matters become complicated because

if (not condition1 or condition 2)

is harder to parse visually because of the space, whereas

if (!condition1 || condition2)

is easier to read because the ! is right up against what is being negated.

[dsaf]

I wanted to suggest custom operators, but it seems that even F# is limiting them to !%&*+-./<=>?@^|~ characters.

[orthoxerox]

@dsaf I usually say I like custom operators, but when I take a look at this I am not sure any more.

[HaloFour]

@orthoxerox Probably only a matter of time before someone writes the full APL set for Apple Swift. life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

[dsaf]

@orthoxerox I did not say I like them :). This is one of my complaints about F# as well.

[alrz]

@HaloFour THAT IS JUST BRILLIANT.

[orthoxerox]

@HaloFour I'm not again custom operators per se, they are very good for internal DSLs, but I wish there was a way to restrict them to obvious places in code, just like computation expressions are wrapped in blah { } in F#.

On the other hand, I wish >>= was a synonym for SelectMany everywhere.

[EgorBo]

I think at least it would be nice to have "is not" or "isnt". Let's say I want to check an object that it's not of some specific type:

if (!(obj is SomeType))

it'd be better to have:

if (obj isnt SomeType)

or even:

if (obj !is SomeType)