Powershell: Feature Request: Adding support for standard comparison operators (>, <, >=, <=, ==, !=)

[sszczepa]

I'm proposing that traditional comparison operators (>, <, >=, <=, ==, and !=) be added to PowerShell as alternatives to -gt, -lt, -ge, -le, -eq, and -ne, respectively.

As someone who regularly switches between multiple programming languages, I've always been a bit annoyed with the syntax for comparison operators in PowerShell. It is unconventional with no obvious benefit, and does not match what is used in the vast majority of programming languages. Furthermore, the way PowerShell handles this currently can introduce tricky bugs. For instance, consider the following error:

if (5 -gt 3) {Write-Output "True"} else {Write-Output "False"} # PowerShell prints "True"
if (5 > 3) {Write-Output "True"} else {Write-Output "False"} # PowerShell prints "False"

For more complicated scripts this type of error could be very frustrating to debug.

As I understand it, part of the philosophy of PowerShell is to be as accommodating and forgiving as possible, and I think supporting traditional comparison operators would be a great improvement to the language, especially for casual PowerShell users who also use other languages. I also think this would help mitigate concerns from potential users who complain about PowerShell's verbose and unconventional syntax.

[jcotton42]

The benefit of -gt/-lt/etc vs >/

If PowerShell used > and < instead then the meaning would change depending on context, which would IMO be more confusing.

[rkeithhill]

with no obvious benefit, and does not match what is used in the vast majority of programming languages.

Keep in mind that PowerShell is not really a general programming language, it is a shell scripting/programming language. As a shell programming language, shell users expect > to redirect input stream to the specified output stream e,g, Get-Process > procs.txt.

[Jaykul]

Yeah. What @rkeithhill said.
You probably didn't notice you created a file named "3" in the second line of your example. The benefit that wasn't obvious _to you_, was that we get shell redirection operators.

[HumanEquivalentUnit]

Being provocative for a moment, if you can get the people who want PowerShell to be as easy as possible for C#-programmers on your side, then you'll have a chance of getting this through.

General comments without actually saying I'm for/against it (because I do still trip over it, and never use > as file redirect anyway); if PowerShell had these operators then they would still not behave exactly like they do in other languages - these use cases might be surprising to people who expect that they will be identical:

"TEST" == "test"    #returns True because -eq is case insensitive.

1,2,3,4,5,6,7,8 <= 5   # returns 1,2,3,4,5  because operators act as filters.

1,2,3,4,5 == 5   # returns 5, not False.

It is unconventional with no obvious benefit

One benefit is consistency; the same syntax can extend from -ne meaning not-equal to -cne and -ine as case-sensitive and case-insensitive, variants. There is no easy way to write case sensitive and insensitive variants of >= which still look like >=. The -ne style allows for operators like -match and -notcontains which have no equivalent in other languages.

This extends further in the way that -gt looks like a cmdlet parameter, and all the operators exist in overloads of the Where-Object parameter sets so you can write the following:

Get-ChildItem | Where-Object Length -gt 10Kb

That -gt is not an operator, it's a parameter for Where-Object which looks like an operator; if PowerShell had > to mean -gt then you might expect to be able to write this:

Get-ChildItem | Where-Object Length > 10Kb

but that would not work as all parameters must begin with -. That would either be an surprising error, or be an unusual special-case for where-object which then wouldn't work elsewhere, or it would have large knock-on changes elsewhere in the language to make it work generally.

Another point is that - in the right place indicates the start of an operator, and tools can use this to offer auto-suggest / intellisense, e.g. if you write 5 - in a console window and press Ctrl+Space then you get a list of available operators with help text indicating what they do. If you are not a programmer from another language and don't know that >= exists, you might have a harder time finding it from scratch.

And if you are a programmer from another language and want to use ==, you will still have to be able to read -eq in all the scripts which already exist, so you don't save as much as you would if you could ignore the -eq style completely.

It's worth pointing out that re: "standard operators", PowerShell's influence here is Unix shells which use -eq: https://www.tldp.org/LDP/abs/html/comparison-ops.html so people coming from other shell scripts would be less surprised by -eq than people coming from Python/C#/Java are. Maybe there's room for doing something like Bash does for indicating a place where > means greater than instead of redirect output to file?

is less than (within double parentheses)

(("$a" < "$b"))

you still wouldn't be able to use that in the same way as in other languages without learning the (Power)Shell specific variant though.

Other Comparison Operators

[sszczepa]

General comments without actually saying I'm for/against it (because I do still trip over it, and never use > as file redirect anyway); if PowerShell had these operators then they would still not behave exactly like they do in other languages - these use cases might be surprising to people who expect that they will be identical:

```
"TEST" == "test" #returns True because -eq is case insensitive.

@HumanEquivalentUnit For string comparisons, you could use '==' for a case insensitive match, and '===' for case sensitive match:

"TEST" == "test"    # Returns True
"TEST" === "test"    # Returns False
"TEST" === "TEST"    # Returns True

Or if that feels clunky, then just have '==' be case sensitive by default and have users use -eq if they want a case insensitive comparison. These new operators wouldn't have to cover all possible use cases, as you could always revert back to the old verbose method if more complex behavior is required; these operators would just be an alternative syntax for the most common use cases.

[bpayette]

@sszczepa

and does not match what is used in the vast majority of programming languages. Furthermore

These operators were adopted from the POSIX.2 shell specification and are present in most Bourne shell derived shells (ksh, bash, etc). So they are probably in the vast majority of the shell languages that people use. @JamesWTruher can probably give you more details if you wish.

[doctordns]

The benefit of -gt/-lt/etc vs >/

If PowerShell used > and < instead then the meaning would change depending on context, which would IMO be more confusing.

When Monad was first being developed, there was a discussion on the mailing list over operators. the general consensus was that while using ">" as an alternative to -GT was attractive, there was one downside which was consistency (that is SOme operators begin with a - and others may not). I believe that was the right answer in 2004 and remains a good one today.