Suggestion: Noninferential type parameter usage

[RyanCavanaugh]

We keep getting bugs like this and I keep not finding the original so I'm making a new one so we can find it.

Keywords: ignore type parameter optional inference

Problem

Often with generics, there will be some locations where a type parameter should be inferrable from usage, and other places where the type parameter should only be used to enforce typechecking. This comes up in a variety of contexts

class Animal { move }
class Dog extends Animal { woof }

function doSomething<T>(value: T, getDefault: () => T) { }
// Wanted an error here - getDefault() ought to return same type as 'value'
doSomething(new Dog(), () => new Animal());

declare function assertEqual<T>(actual: T, expected: T): boolean;
const g = { x: 3, y: 2 };
assertEqual(g, { x: 3 }); // Forgot y, wanted error

Proposal Sketch

We should be able to mark type parameter consumption sites as being "not eligible for inference". For example, let's say we had a special global type that the compiler knew not to unwrap during inference:

type NoInfer<T> = T;

Then we can annotate usage sites

function doSomething<T>(value: T, getDefault: () => NoInfer<T>) { }
// Wanted an error here - getDefault() ought to return same type as 'value'
doSomething(new Dog(), () => new Animal());

declare function assertEqual<T>(actual: T, expected: NoInfer<T>): boolean;
const g = { x: 3, y: 2 };
assertEqual(g, { x: 3 }); // Error

[mhegazy]

Is using multiple type parameters not an option?

function doSomething<T, U extends T>(value: T, getDefault: () => U) ;

function assertEqual<T, U extends T>(actual: T, expected: U): boolean;

[johnfn]

@mhegazy, speaking from my experience, I never ever would have guessed that

function doSomething<T>(value: T, getDefault: () => T) ;

could be amended to do what I want by changing it to

function doSomething<T, U extends T>(value: T, getDefault: () => U) ;

Multiple type parameters are an option! It's just that right now they are a very surprising and unintuitive one.

[mhegazy]

I would not have guessed that NoInfer was the solution :)

[PyroVortex]

Unfortunately, using the U extends T option has inconsistent behavior for contextual typing, due to the subtly different semantics.

declare function invoke<T, U extends T, R>(func: (value: T) => R, value: T): R;

declare function test(value: { x: number; }): number;

invoke(test, { x: 1, y: 2 }); // Works
test({ x: 1, y: 2 }); // Compiler error

[RyanCavanaugh]

Need to collect some use concrete cases before attempting to move forward with this

[ajafff]

I also ran into the problem that U extends T allows excess properties as @PyroVortex mentions above.

I found a rather simple work around: {} & T
The example above would then be:

declare function invoke<T, R>(func: (value: T) => R, value: {} & T): R;

declare function test(value: { x: number; }): number;

invoke(test, { x: 1, y: 2 }); // Compiler error
test({ x: 1, y: 2 }); // Compiler error

[RyanCavanaugh]

@ajafff 😲 !

I would expect { } & T to be indistinguishable from T - not 100% sure if this is a bug or not but I would not take it as designed behavior.