Powershell: Extended operators support

[sevenam]

I realise that Powershell is not c#, and this is probably asking a lot, but:
I think Powershell code would be less awkward to write, if it had aliases/support for the following:

Can -lt also be: <
Can -gt also be: >
Can $true also be: true
Can $false also be: false
Can -eq also be: ==
Can -ne also be: !=
Can -le also be: <=
Can -ge also be: >=
Can -or also be: ||
Can -and also be: &&

PS (no pun intended): Every time I write Powershell scripts I have to think really hard to remember if -lt is LargerThan or LessThan :)

[ygra]

< and > are redirection operators. They already have a meaning in a shell.

true and false would probable have to become yet another class of literals. Currently they aren't supported by the grammar in that way, but variables are. Furthermore, there is rarely a need for them in most scripts (except maybe for passing a boolean value to a .NET method).

|| and && have different semantics than -or and -and regarding return values and what happens with output. PowerShell not having || and && can be annoying, but I'm fairly sure it doesn't exist so far because people haven't found a viable way how to make it work in an object-based shell where program output is the result of the expression running said program, for example.

[sevenam]

This request is only for convenience of course, to make it quicker to write Powershell.

• < and > should’t have a meaning inside a statement even in a shell though?
• Looking in my script "history", I tend to use true/false quite frequently in scripts (mostly boolean functions), but maybe I’m doing it wrong.

Maybe a better way for this productivity change would be an extension for Visual Studio Code or similar, that would simply fix typos (e.g. replace < with -lt if used inside a statement).

[jpsnover]

We tired to do this many times in the early days of PS but the only way we could disambiguate the syntax was by changing the redirection operators. We proposed changing them (we might have actually released a beta) to :> and :<

e.g.
instead of:
PS> GPS > t.txt
you would type
PS> GPS :> t.txt

The feedback from the community was EXTREMELY VOLUMINOUS AND CLEAR - NFW!

That's how we ended up keeping -lt -gt etc.

[rkeithhill]

And, as C# dev switching back and forth between C# & PowerShell, I will occasionally use the wrong operator. But I fix it and move on.

What I really like about the -<operator> approach is that PowerShell can (and does) provide a very rich set of operators. Many more than the set of available special characters on a typical keyboard. :-)

Plus this approach is consistent with other shells like Bash. Remember, PowerShell is a shell scripting language and not a general purpose programming language.

[joeyaiello]

I'm also in the camp that we should close this as "by design", as I don't see a way of supporting this without changing the existing redirection operators or their behavior.

/cc @PowerShell/powershell-committee to give them a chance to disagree with me before we close it.

[SteveL-MSFT]

I think @rkeithhill touched upon an important data point which is the current syntax allows for many more operators. Adding an optional secondary way to represent a subset of the operators may make reading scripts more confusing. Agree with "by design". I think if the community wants to pursue this further, someone should author a RFC.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this and agreed that this is by-design. we don't want to introduce multiple ways to do the same thing which leads to confusion