Proposal: syntax sugar for binary compare expressions

[tinganho]

Auto referring to last identifier:

Instead of:

if(value > 2 && value !== 3) {}

we can have this:

if(value > 2 && !== 3) {}

Auto referring to last identifier and operator:

Instead of:

if(value === 2 && value === 3) {}

we can have this:

if(value === 2 && 3) {}

Range comparisons:

for numbers:

if(value === 1..3) {}

for enums:

if(value === Enum.something...Enum.somethingElse) {}

[DanielRosenwasser]

Hey @tinganho, thanks for the suggestions, however, you'll have to understand that we tend to be somewhat conservative when it comes to syntax. Additionally, I'm not sure that these fall in line with the direction of our language.

if(value === 2 && 3) {}

Definitely not something we could do, this is already syntactically valid, and part of common patterns.

if(value === 1..3) {}
if(value === Enum.something...Enum.somethingElse) {}

We'd be reinventing new semantics for ===. Even worse, if a range operator ever made its way into ECMAScript, the expected semantics would probably not match this.

if(value > 2 && !== 3) {}

I think this syntax this strays too far from the general direction we want to move in, as well as the direction of JavaScript itself.

[tinganho]

@DanielRosenwasser I missed the valid syntax part. Though these are problems I currently have today(typing the same identifier too many times).

[cyberpunk2099]

I think you may consider 'in' operator for range checks, like:

if(value in 1..3)

or

if(value in Enum.something..Enum.somethingElse)

or even

if(value in Enum.something..Enum.somethingElse, Enum.somethingSpecial)

So that you won't have to reinvent new semantics for ===

[tinganho]

I think I also have seen this syntax somewhere: I think Swift.

if(object.property?.subProperty) {}

will be the same as:

if(object.property && object.property.subProperty) {}

[RyanCavanaugh]

These are all suggestions that are on the table for ES7 or later, and thus need to be avoided by TypeScript until their semantics are fully understood.

For example, the safe navigation operator can't be simply decomposed as written because there are values which are safe to dot off of that are still falsy:

var x = { n: "" };
var y = x?.n?.length; // y should be 0, not undefined or ""

[DanielRosenwasser]

Also, any discussion on that feature should not be continued here, as it's tracked under #16.