Define assignability relation for primitive-constrained type parameters

[RyanCavanaugh]

The spec does not define any case in Assignment Compatibility where S is a type parameter constrained to a primitive type and T is that same primitive type.

This leads to some weird errors, e.g. T is not assignable to number even though T extends number:

enum E { A, B, C }
enum F { X, Y, Z }

function f<T extends number>(x: T[]): T {
    var y: number = x[0]; // Error, T is not assignable to number...??
} 

// f<T extends number> is useful:
var x = f([E.A, E.B]); // ok, x: E
var y = f([F.X, F.Y]); // ok, y: F
var z = f(['foo', 'bar']); // Error

See also http://stackoverflow.com/questions/29545216/inconsistent-behavior-of-enum-as-constrained-parameter-in-generic

[dsherret]

If primitive types aren't allowed to be extended, then how is writing T extends number useful and why should it be allowed? It doesn't seem to constrain anything in the language.

Someone could always write the above function this way, which I think makes more sense:

function f(x: number[]) {
    var y: number = x[0];
} 

Or maybe I'm missing something?

[RyanCavanaugh]

If primitive types aren't allowed to be extended, then how is writing T extends number useful and why should it be allowed?

See the examples var x, var y, and var z in the original post. Enum members are subtypes of number, and it's useful to chain the type of the input of the function to its output while also restricting what kinds of types the function can handle.

[dsherret]

Ok, that makes sense.

Btw, it might be beneficial to add the ability to constrain by enum or an EnumMember.

[jeffreymorlan]

It's not only primitive types where the lack of assignability of a type parameter to its constraint hurts; I've also run into this with unions. Here's a real example of that:

interface ComparableObject { compare(other: ComparableObject): number; }
type Comparable = number | string | ComparableObject;

function compare(a: Comparable, b: Comparable): number {
    // ...
}

function binarySearch<T extends Comparable>(array: T[], element: T) {
    // ...
    compare(array[i], element) // Error: T not assignable to Comparable
    // ...
}

It gets even worse with class hierarchies:

class Column<T extends Comparable> {
    getValue(row: number): T { return; } // abstract
    render(value: T, node: HTMLElement) {} // abstract
    sort(rows: number[]) {
        // More errors here...
        return rows.sort((a, b) => compare(this.getValue(a), this.getValue(b)));
    }
}

// Yet another error here - and no way to hack around it with casts!
class FancyColumn<T extends Comparable> extends Column<T> { /* ... */ }

I don't understand why subtyping/assignability of type parameters needs to have a separate rule for every kind of constraint (object, primitive, union, another type parameter, ...) - seems that just one general rule should suffice: "S is a type parameter, and S's constraint is (a subtype of|assignable to) T."

[RyanCavanaugh]

Approved

[JsonFreeman]

@jeffreymorlan the unions issue is fixed by #2778. But as you mention, it does seem silly that every kind of constraint has to be accounted for. Probably the more correct thing to do is to recursively check if the base constraint of S is assignable to T

[mkantor]

I stumbled across this ancient issue and if I'm understanding it correctly I think it can be closed. These days code like this legal:

function f<T extends number>(x: T) {
  const y: number = x // no error
}