Should unions and non-primitives be allowed for relational comparisons?

[DanielRosenwasser]

To quote 4.19.1 of the spec:

4.19.3 The <, >, <=, >=, ==, !=, ===, and !== operators

These operators require one or both of the operand types to be assignable to the other. The result is always of the Boolean primitive type.

	Any	Boolean	Number	String	Other
Any	Boolean	Boolean	Boolean	Boolean	Boolean
Boolean	Boolean	Boolean
Number	Boolean		Boolean
String	Boolean			Boolean
Other	Boolean				Boolean

This has probably unintended consequences in the case of union types:

var x: string | number = "hello";
var y: number = 10;
var z: string | number = -1;

if (x < y && x <= z) {
}

The question is: is this still desirable behavior?

@ahejlsberg @RyanCavanaugh @danquirk @mhegazy @JsonFreeman

[LPGhatguy]

Comparing strings and numbers is perfectly valid (if not a little wacky) JavaScript, isn't it?

[weswigham]

I mean, comparing anything is "valid javascript" (objects, arrays...), if not obviously meaningful.

[DanielRosenwasser]

From an offline discussion, the consensus seems to be that the equality operations could keep something like this behavior, whereas other comparison operators should have their own rules.

[mhegazy]

We should keep the idea of a new relationship on the backlog, i do not think we solved the underlying issue. closing this to avoid duplication though.

[DanielRosenwasser]

This wasn't regarding the comparable relation, and even if it was, we've decided to use it for nullable types.

[DanielRosenwasser]

I think that this is a bug and that >, >=, <, and <=, should probably be separated out from this chart and treated independently.

[jasonswearingen]

why are relational operators valid for non-primitives in typescript?

given that typescript is to make type checking pracical in javascript, I find it remarkable that things like the following do not give syntax errors:

var a={};
var b=2;
if(a>b){ } //i would expect a syntax error

[jasonswearingen]

further, why allow relational operations at all for non-primitives as they are useless and indicative of a coding or logic mistake?

var a={};
var b={};
if(a>b){ } //typescript should give a syntax error, but does not.

[jasonswearingen]

after reading the original bug, maybe what I am posting is slightly different (a regression?) so maybe this should be a separate issue.

edit: hmm, it seems like some object types can do relational operations correctly (such as Moment objects) so maybe I am wrong about this. would like to hear other opinions!

[DanielRosenwasser]

I have been looking into this again - one direction that I've taken has been that two variables of type string | number should not be comparable in a relational manner (i.e. using <, >=, etc.), since each value could be of the other type. I've also gone down the path that a type parameter is only relationally comparable to a type if its constraint is.

One question I ran into is whether this code should be allowd to be wrong:

export function compareValues<T>(a: T, b: T): Comparison {
    if (a === b) return Comparison.EqualTo;
    if (a === undefined) return Comparison.LessThan;
    if (b === undefined) return Comparison.GreaterThan;
    return a < b ? Comparison.LessThan : Comparison.GreaterThan;
}

Now, this function is "bad" in some sense - substituting T with anything other than number or string (and I guess boolean) will have questionable behavior. (Though keep in mind that the function has never been used badly!)

In any case, let's assume that we want to fix this. Let's start writing two overloads:

export function compareValues(a: number, b: number): Comparison;
export function compareValues(a: string, b: string): Comparison;

Looks decent so far. Now what about an implementation signature?

export function compareValues(a: ???, b: ???): Comparison {
    if (a === b) return Comparison.EqualTo;
    if (a === undefined) return Comparison.LessThan;
    if (b === undefined) return Comparison.GreaterThan;
    return a < b ? Comparison.LessThan : Comparison.GreaterThan;
}

What can you put in for ???? number | string won't work because then one can be a number and one can be a string. Really what I'd like to say is that if a has a union type, then b is of an appropriate branch of that type for the purposes of comparison.

It's not entirely clear what to do here, but I think "good enough" might be the place to land.

[RyanCavanaugh]

Seems we fixed this. Sometime things just work out!