Flag boolean in comparison operator operands as errors

[mhegazy]

From #15444 (comment)

var x: boolean, y: boolean;
if (x > y) {  // suspicious!
}

[dmichon-msft]

Well, that is the most concise way of writing:

let x: boolean, y: boolean;
if (x && !y) {
}

[RyanCavanaugh]

Accepting PRs: Disallow non-any/number/string operands on either side of <, >, etc.. Should be an easy change

[Jessidhia]

Should {} also be comparable?

At least I have used it in the past to indicate a "comparable" that was not any (i.e. couldn't do anything with it other than compare; using any would allow property access and other shenanigans).

[DanielRosenwasser]

Should {} also be comparable?

Could you elaborate on the scenario? What was the run-time value supposed to be?

[Jessidhia]

In this specific case, it was a function that received a function that produces an ordered list of sorting keys; where the value of the sorting keys are anything comparable. As the function doesn't need the keys to be anything in particular (besides comparable), they were typed as {} (instead of any). At the time that included both numbers and Date objects.

Speaking of which, are Date objects comparable because of spec magic, or because of Symbol.toPrimitive 🤔

[RyanCavanaugh]

Speaking of which, are Date objects comparable because of spec magic

Extreme spec magic; see #2361 (comment)

[FabianLauer]

I've just taken a stab at this issue. The conformance tests for comparison operators work as expected. However, a few tests still fail, such as:

// asyncFunctionDeclaration5_es5.ts

    async function foo(await): Promise<void> {
                       ~~~~~
!!! error TS1138: Parameter declaration expected.
                       ~~~~~
!!! error TS2304: Cannot find name 'await'.
                            ~
!!! error TS1005: ';' expected.
                             ~
!!! error TS1128: Declaration or statement expected.
                               ~~~~~~~~~~~~~~~
                                       ~~~~
!!! error TS2532: Object is possibly 'undefined'.
                                           ~
!!! error TS1109: Expression expected.
    }
    ~
!!! error TS2365: Operator '>' cannot be applied to types 'boolean' and '{}'.

... or ...

// parserTypeAssertionInObjectCreationExpression1.ts

    new <T>Foo()
    ~~~~~~~~~~~~
!!! error TS2365: Operator '>' cannot be applied to types 'boolean' and 'any'.
        ~
!!! error TS1109: Expression expected.
         ~
!!! error TS2304: Cannot find name 'T'.
           ~~~
!!! error TS2304: Cannot find name 'Foo'.

Am I right to assume that this is an issue with (graceful) parsing? If so, should I deal with this in a new issue?

I've not opened a PR yet, BTW. Can do though if you prefer to. Any guidance is much appreciated 🙂

[mhegazy]

Am I right to assume that this is an issue with (graceful) parsing? If so, should I deal with this in a new issue?

yes.

[gcnew]

Maybe late to the party, but I think Date should be comparable as well. It's true that the arithmetic operators yield strange results, but AFAIK the relational ones do not and are frequently used in JS sources.

[staeke]

@gcnew Came here from issue #17119

As the comments stand now, I don't think this issue is a clear duplicate, and if we're keeping addressing that issue in this thread, then at least I want to make it clear. As the reporter @adius said, it would be nice if typescript produced a warning for below (d1, d2 are Dates)

d1 === d2
d1 == d2

As @gcnew pointed out <, >, <=, >= work fine

[Richard-Lynch]

Working on this, I’ll follow up with a PR via Bloomberg in the by Monday

[HersiYussuf]

I would love to work on this if no one hasn't already or working on it now with a bit a of help!!

[HersiYussuf]

Working on this, I’ll follow up with a PR via Bloomberg in the by Monday

I want to work with on it, can I ?