Type parameters in custom type guards don't seem to have the same meaning as in their predicates

[zpdDG4gta8XKpMCd]

I know I am not supposed to use values of void, because one day they might be banned. But for time being I don't understand is it by design or by mistake that the isVoid guard works whereas isNonVoid doesn't in the example below:

function isVoid<a>(value: void | a): value is void {
    return undefined;
}

function isNonVoid<a>(value: void | a) : value is a {
    return undefined;
}

function foo<a>(value: void|a): void {
    if (isVoid(value)) {
        // value is void
    } else {
        // value is a
    }
}

function baz<a>(value: void|a): void {
      if (isNonVoid(value)) {
            // value is void | a
      } else {
            // value is {}
      }
}

How come that seemingly identical guard implementation breaks apart entirely?

[tinganho]

@Aleksey-Bykov notice that you are using a type parameter a in isNonVoid and you are passing the type value | a for the type parameter a in the predicate value is a.

And at the else clause you are subtracting the type value | a from value | a which I presume will result in type {}.

[zpdDG4gta8XKpMCd]

why does the value is a predicate treat void | a as a? in other words a in value is a is not the same a as in void | a.

if I understood your right how isNonVoid is defined could have been just as well written as:

function isNonVoid<a>(value: void | a) : <b>(value is b) {
    return undefined;
}

but that is at very least surprising that the knowledge about what a is is not propagated to the predicate

[wgebczyk]

@tinganho Please notice that this is not the first time when people sees guard expressions as working in unexpected way. Please search for all issues (open and closed) and you see that something is wrong with them. Either this construct in not natural to people or the people that have problem should not use TS as they are not target group.

[tinganho]

@Aleksey-Bykov Sorry, after looking at it more closely it probably is a bug.

[tinganho]

I just noticed that type parameter matching for union types does not work on the following case too:

function f<T>(x: string | T): T {
    return undefined;
}

let a: string | number;
let b = f(a); // b: string | number, while it should be number?

[zpdDG4gta8XKpMCd]

Was there any luck figuring out whether it is a bug or was done by design?

[danquirk]

Seems like a bug if the type predicate is intended to work the same as other type guard forms. That is, if you apply this logic (from 4.24 in the spec):

• A type guard of the form typeof x === s, where s is a string literal with the value 'string', 'number', or 'boolean',
o   when true, narrows the type of x to the given primitive type provided it is a subtype of the type of x, or, if the type of x is a union type, removes from the type of x all constituent types that aren't subtypes of the given primitive type, or
o   when false, removes the primitive type from the type of x.

it seems like the two cases in the original post should work as you expected and not how they are at the moment.

[tinganho]

@danquirk If this is a bug then probably my above comment is also?

function f<T>(x: string | T): T {
    return undefined;
}

let a: string | number;
let b = f(a); // b: string | number, while it should be number?

TS doesn't seem to remove matched types before the type parameter is decided. Though I would argue that if you have more than 1 type parameter it would be very hard to decide which type the type parameter should have.

function f<T, U>(x: string | T | U): T {
    return undefined;
}

let a: string | number | boolean;
let b = f(a); // what should type of b be? 

[danquirk]

It's not clear whether that's really desirable. For instance:
let c = f('hello');
Did you want c to be {} here? Or is string a valid type for T and c should be string?

[zpdDG4gta8XKpMCd]

if I were you I would have banned unions with more than one bare type parameter

i mean from practical stand point f<U, T>(x: U|T) is the same as f<W>(x: W) because in both cases f has no idea what it deals with be that some U or some T or just some W

[tinganho]

I'm not sure whether this is desirable or not to have the functionality in my previous comment. Though my point is that my described problem is the same as OP?

function baz<a>(value: void | a): void {
      if (isNonVoid(value)) {
            // value is void | a
      } else {
            // value is {}
      }
}

Notice the parameter type for isNonVoid is void | a, where a is a type parameter. It's quite similar to me described problem above. And if you don't think it is desirable. Then this feature should not be desirable for type guards too.

[zpdDG4gta8XKpMCd]

I think situations like in isNonVoid are valid and should be supported just like anything else that involves a union with not more than one type parameter

unions with more than one type parameter regardless of the context should end up with a compilation error

[zpdDG4gta8XKpMCd]

@ahejlsberg, there seems to be an unresolved question related to how TypeScript is designed, would you please take a look?