Method return type cannot be used as discriminant

[kyranet]

Bug Report

When having objects with methods that return a boolean, the types don't get narrowed when checked, contrary to properties.

🔎 Search Terms

type guard, narrowing

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about type narrowing with methods returning strict literals in the types

⏯ Playground Link

Playground link with relevant code

💻 Code

class Some<T> {
  public readonly value: T;
  public constructor(value: T) {
    this.value = value;
  }

  public isSome(): true { return true; }
}

class None {
  public isSome(): false { return false; }
}

type Option<T> = Some<T> | None;

declare const x: Option<string>;

if (x.isSome()) {
  x.value;
  // Property 'value' does not exist on type 'Option<string>'.
  //   Property 'value' does not exist on type 'None'.(2339)
}

🙁 Actual behavior

isSome() does not narrow the type from Option<string> to Some<string> unless the return type of isSome() in either or both classes are typed as this is Some<T>:

Some#isSome()	None#isSome()	Narrows?
true	false	❌
this is Some<T>	false	✅
true	this is Some<any>	✅
this is Some<T>	this is Some<any>	✅

This behaviour is not consistent to the one when typed properties (public some: true = true/public some: false = false) are used, where the type narrowing system works perfectly fine.

🙂 Expected behavior

isSome() would be sufficient to narrow Option<string> to Some<string>, as is the case with regular properties (Playground link). In short, the first case in the aforementioned table should work.

[RyanCavanaugh]

The return type of methods isn't currently used as a discriminant. AFAIR this is the first anyone's ever asked.

[kyranet]

In case by more feedback it means from me... I'm maintaining a strict port of Rust's Result and Option types, as seen here, and since it uses methods to determine the variant, it would be incredibly useful if their return types could be used as discriminant.

We have gone for isSome(): this is Some, however, this makes Some#isSome() and None#isSome() return boolean rather than the stricter true and false, and those aren't the only methods that would benefit from narrowing (in fact, quite a bunch of them are able to), the following is also a valid case:

class Ok<T> {
	public constructor(public readonly value: T) {}
	public unwrap(): T {
		return this.value;
	}
}

class Err<E> {
	public constructor(public readonly error: E) {}
	public unwrap(): never {
		throw new Error('error');
	}
}

type Result<T, E> = Ok<T> | Err<E>;

declare const result: Result<number, Error>;

result.unwrap(); // Technically `number | never`, but is `number`
result.value;
// Property 'value' does not exist on type 'Result<number, Error>'.
//  Property 'value' does not exist on type 'Err<Error>'. TS(2339)

(Playground link).

And it should definitely narrow, as never results on the code below to be "unreachable code" (Unreachable code detected. TS(7027) on an always-never returning function), so by this logic, if never wasn't reached, then it means it returned number, which should be enough to discriminate the union down to Ok<number>, I'm unsure if this is related to this issue or just a similar one, but mentioning it just in case.