GeezerVison

nice 🏆

Can you add an example where you orphan your type guard method to a function?

Jason Freeman (@JsonFreeman) I realized that the way that Wesley Wigham (@weswigham) has implemented this, we could discriminate on generators being finished or not.

Daniel Rosenwasser (@DanielRosenwasser) Is that the case? If I understand you correctly, you mean that to check if an iterator/generator is done, you would do

if (iterResult.done) {
    ...
}

Is it possible to use a type predicate on a property declaration? If not, it looks like you'd have to define the done property as a getter. I'm not sure if this is a problem, but it's worth noting. I guess accessors are treated the same as properties, so in theory it might be okay, it just looks weird to define it that way.

The real issue is that a type predicate can only tell you whether this is of a certain type, given its done value. It cannot tell discriminate between two types based on the done value. So would the definition of IteratorResult be something like this (given a type SuspendedType for done: false, and CompletedType for done: true)

{
    value: SuspendedType;
    done: this is { value: CompletedType };
}

Is this the correct definition? I guess this is how you would discriminate between the two types. But if CompletedType is not assignable to SuspendedType, then will the type guard even apply? I think it will still give you SuspendedType.

If I understand you correctly, you mean that to check if an iterator/generator is done, you would do

if (iterResult.done) {
    ...
}

Jason Freeman (@JsonFreeman) yes, that's exactly correct.

Wesley Wigham (@weswigham) has allowed these predicate types on properties because it is necessary to support them on getters as well. It is slightly surprising (at least it was for me), but I don't necessarily see anything wrong with it^[1]. It's no more than a boolean that is used as an indicator for the type, and that's being encoded into the type.

You might be correct in that weakness though Wesley Wigham (@weswigham) can weigh in. We should have some samples on this.

I think the interface we'd end up with is

interface IteratorResult<CompletedType, SuspendedType> {
    value: CompletedType | SuspendedType;
    done: this is { value: CompletedType };
}

^[1] There's an issue regarding "orphaning" the property, whereby we don't orphan the type to boolean:

let x = {
    p: this is Whargarbl,
}
let y = x.p; // 'y' has type 'this is Whargarbl'

Oh... why is the type of y in your last example a type predicate? In the initial design of type predicates, they denoted type boolean, and the narrowing semantics did not flow around along with the value. I'm curious why this has changed.

Barring that, I think supporting type predicates on properties is fine.

As for IteratorResult, the type you wrote is technically accurate (more so than mine), but it spoils the element type of an iterator, which is supposed to be SuspendedType in the example. This was one of the major challenges of typing generators, and may have to be revisited if generators become more fully supported in the type system.

Is it spoiled? I think we could still appropriately negate the guard on the union of value and end up with SuspendedType like we would want - not CompletedType | SuspendedType.

That would involve type subtraction semantics. You would have to have way in the type system of seeing { value: CompletedType | SuspendedType }, and then subtracting from it, { value: CompletedType }, and getting the result { value: SuspendedType }. In order to do this, you would need to make a lot of very specific assumptions about the structure of IteratorResult. That might be okay if you check that all these assumptions hold, when you process lib.d.ts. That way you could ensure up front that this type subtraction would be well defined when you needed it. Also, is the expectation that this subtraction would apply in the false branch of a type guard on done, in addition to iteration constructs?

But I believe we actually do "the right thing" with user defined type guards:

function f(x): x is { p: string } {
    return true;
}

var v: {
    p: string | number;
}

if (f(v)) {
    v.p // 'p' has type 'string'!
}

I mean in the else block, does v.p have type number? That's the sort of thing you would need for iteration. Because in iteration, done is false.

Ah, that wouldn't be covered unfortunately, and you're right.

Why is a type predicate still effective after a property is orphaned?

And can you do generators with my proposed type, or does the type guard only take effect if the guard type is assignable to the original type?

{
    value: SuspendedType;
    done: this is { value: CompletedType };
}

Assignable

Why is a type predicate still effective after a property is orphaned?

Because that's the way it just currently works. We were looking into how to shed it properly following an assignment. You can't do it as part of widening because you don't want to "dive in" to the type you're widening.

Why not just have the property be of type boolean to begin with? The type predicate only needs to take effect on a property access type guard. And that can be achieved by fetching the type predicate associated with the property symbol. The type predicate's narrowing semantics don't need to be trafficked through the property's type.

Jason Freeman (@JsonFreeman) I've been able to unify all type predicates into predicate types with minimal changes to baselines (our type baseline writer doesn't get widened types, so when it prints out the values of predicate returning functions it now prints the predicate rather than boolean, which is a mostly cosmetic change as far as our baselines are concerned) - the typePredicate field on Signature is no more. At Daniel Rosenwasser (@DanielRosenwasser)'s request, I've preserved some old behavior regarding the assignability of boolean-returning functions to type-predicate returning functions (ie, they're not assignable) which was likely to change so that allowing this can be saved for a later discussion.

Wesley Wigham (@weswigham) Thanks for the update. I have a few thoughts:

1. In terms of displaying the type, will quick info widen the type to boolean, or will it behave like type writer?
2. In terms of assignability of boolean-returning functions to type predicate-returning functions, I can see arguments for both, but I agree with Daniel Rosenwasser (@DanielRosenwasser)'s intuition about keeping it the same for now. It seems they probably should not be assignable, but then again, a boolean is assignable to a type predicate when it's not in return position.
3. You said "I propose not checking subtype assignability to the this type of this type guards (however, narrowing will still check if the type if a subtype to actually narrow)." What is the difference between the two checks you're referring to, in terms of the source type and target type for each?
4. This issue of vacuous truth and falsity does not seem unique to this type predicates, or even type predicates. It seems to apply for type guards across the board. I don't think it's a serious issue, but it's probably best to have a consistent policy for all type guards.
5. The widening approach we discussed seems like it would have a strange effect for function expressions and object literals. Would the following variables have different types?:

var v1: (x: any) => x is T;
var v2 = (x: any): x is T => true; // Does this widen?

var v3: { isT(): this is T; };
var v4 = { isT(): this is T { return true } }; // Does this widen?

It would seems unintuitive to me if v1 and v2 are different, or if v3 and v4 are different.

Jason Freeman (@JsonFreeman)

1. Since it widens to boolean, in all meaningful situations (assignments, returns), it gets reinterpreted as a boolean.
2. And so it is, for now.
3. The check we do on type guards is that the RHS is a subtype of the LHS, meaning, in this case, that the RHS should be a subtype of the polymorphic this type - which is rather constraining, since this could mean that you can't guard from a base type to a sub-type. When narrowing, we check that they type guarded against is a subtype of the specific type being guarded on, and only narrow if this is the case (so you never narrow "across the lattice" as Daniel Rosenwasser (@DanielRosenwasser) once put it).
4. We check, for parameter type guards, that the type of the parameter is a supertype of the type guarded against in the return type, hence why I stated that we should have not perform the equivalent for this guards, as it would be extremely limiting.
5. v1 and v2 are the same type, since we only widen on assignments/declarations - we never widen when the user has actually specified a predicate as the function's return type. v3 and v4 are both invalid because there is no polymorphic this available at those locations, but even if they were, there would be no widening in this location because, again, we don't widen return types within the signature.

By the way, as Daniel Rosenwasser (@DanielRosenwasser) pointed out, the unification also makes this possible:

interface Array<T> {
  filter<U extends T>(f: (item: T, index: number, array: T[]) => item is U): U[];
}

var x: (string | number)[]

function isString(x: any): x is string {
    return typeof x === "string";
}

var y = x.filter(isString); // y is inferred as string[]

It's awesome.

👍

Oh, so when you widen a function, you don't widen its declared return type.

I think my confusion about the "narrow across the lattice" point, is that I don't see the difference between the type being guarded, and the polymorphic this type (once instantiated). Are these in fact two different types? Or does "polymorphic this type" mean the uninstantiated / generic type?

And I agree that the type argument inference for type predicates is pretty nifty. Though I am not sure that the return type of a generic function at run time can realistically be related to the type predicate of a callback that's passed in.