Empty type {} gets inferred to without a warning

[zpdDG4gta8XKpMCd]

function isOkOf<a>(anything: { isOk: a }) : a {
    return anything.isOk;
}
function notOver<a>(is: (value: a) => boolean) : (value: a) => boolean {
    return function not(value: a) : boolean {
        return !is(value);
    };
}
interface A {
    isOk: boolean;
}
var values : A[] = [{ isOk: true }];

values.map(notOver(isOkOf)); // <-- expected: compilation error, actual: `a` inferred to {} without a warning

[DanielRosenwasser]

When you say you expect an error, you mean because of the failure to find candidates for type arguments, not for any other reason, right?

If so, this sounds like a duplicate of #360.

[zpdDG4gta8XKpMCd]

Yes. Somehow I thought #360 was shipped with 1.4, wasn't it? I saw it my self giving errors in a LKG a while ago.

[zpdDG4gta8XKpMCd]

https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#stricter-generics

[DanielRosenwasser]

No, that relates to if we are unable to find a common supertype as in the following:

function f<T>(x: T, y: T) {
    // ...
}

f(10, "hello");

[zpdDG4gta8XKpMCd]

Sorry for the unrelated question, is the milestone for shipping #360 set?

[JsonFreeman]

Your code looks correct, but maybe you are talking about the case where values is not an A[]? In that case, isOkOf expects something that has an isOk property, but you will not have one if values is {}[] for example.

[zpdDG4gta8XKpMCd]

Well, I think the code is unsound and vulnerable to refactoring. Consider

var values /* : A[] */ = [{ isDeliciousPizza: true }];

values.map(notOver(isOkOf)); // <-- still no warnings

[JsonFreeman]

I would also add that the compiler does two odd things with your original repro:

• The a from notOver is inferred to {} because it's fixed before it has any candidates, and we don't report an error on this.
• By the time we have to compare isOkOf to is, isOkOf has been instantiated to any. So even though we never find out that the a of isOkOf is a boolean, we don't give an error about this.

[JsonFreeman]

Yes, the vulnerability you note is my point exactly. Because isOkOf is generic, we end of fixing the a of notOver, and then we lose the type argument inference we would have gotten. It would be awesome if we could still infer from the structure of anything, even though we don't yet know what the a of isOkOf is yet.

[JsonFreeman]

You can test that out by making isOkOf not generic. I believe you should now get an error.

[zpdDG4gta8XKpMCd]

You can test that out by making isOkOf not generic. I believe you should now get an error.

Well, the whole point it to have isOkOf generic for dryer / more reusable code base.

It would be awesome if we could still infer from the structure of anything, even though we don't yet know what the a of isOkOf is yet.

Wouldn't it? May I dare to ask if there is any chance for TS to ever get Hindley Milner sort of type system?

[JsonFreeman]

Perhaps you are asking for us to infer the A for the a in notOver, based on the return type of notOver. That would allow us to plumb it through to the parameter of is. This would be a significant change to our type argument inference algorithm. But this may potentially be the right thing to do in the absence of inference candidates.

[JsonFreeman]

I mean as a fallback.

[JsonFreeman]

I can think of 4 options here:

1. Use contextual signature instantiation during assignability. This would give an error in your original example, and in the delicious pizza example. It also makes the type system much stricter with respect to generics.
2. Give an error when {} is inferred because there are no inference candidates. We have discussed this option before, and it never really gained much traction, but we could revisit. Again, it would give an error in both your examples.
3. When the return type of the signature is a function type, we can treat the signature as a curried function and also infer to its return type's parameters. The inferences would come from the contextual type of the call. This would be done recursively until we hit a return type that is not a function type. This would add some complexity in overload resolution, but it's also kind of nice. It would not really make the type system stricter like option 1, just smarter when this pattern arises. It would not error in your original example, but would error in the delicious pizza example, which is the most correct behavior. I think it's my favorite option because it's the most targeted fix.
4. Do nothing.

[JsonFreeman]

Actually 3 is more complex than I thought. Previously a contextual type could have no effect on a call expression. With this proposal it would. The tricky part is that we'd have to add another condition for fixing type parameters as a result of contextually typing a call expression.

[JsonFreeman]

The other complex thing about it is that it messes with the arity of the signature and the number of arguments being passed, and I can't figure out how that would interact with spread and rest.

[DanielRosenwasser]

There's a branch that has suggestion 2 called downWithDreadedCurlyCurly. Haven't really touched it in a while though.

[zpdDG4gta8XKpMCd]

I like the best options 1 then 2.
3 - is too specific for the case
4 - doesn't change anything

[ahejlsberg]

I'm closing this one since it looks to be covered in #3423.

[zpdDG4gta8XKpMCd]

@ahejlsberg, I am afraid this request is a related, but separate issue
If so, I would reopen it, consider:

interface A<Z> { z: Z }
declare function fn<X extends A<Z>, Z>(value: X): void;
declare var a: A<number>;
fn(a); // <-- a problem: fn<A<number>, {}>

I would like the "inferred" empty type was flagged by the compiler.