SUGGESTION: Set and Map '.has' method as type guard

This is a small suggestion, but I think it can be interesting to bring this type of characteristics to the spirit of the typescript language.

Code

function actual(value: string|number) { 
    let numbers = new Set<number>();

    if (numbers.has(value))  // Error: Type 'string' is not assignable to type 'number'.
        value  
         // we need to do
    if (numbers.has(value as number)) 
        value = value as number 
}

declare class MySet<T> {
    has(elem: any): elem is T;
}

function suggested(value: string|number) 
    let numbers = new MySet<number>();

    if (numbers.has(value)) // OK, we are doing a legal checking
        value // <= value is a 'number'
}

thank you for your attention.

I don't think this is a great idea, for a few reasons. The most obvious one is this:

declare let numbers: Set<number>;
declare let value: string | number; 
if (numbers.has(value)) {
  value + 2 // narrowed to number, okay
} else {
  value.charAt(0); // narrowed to string?!
}

If a Set<T> doesn't contain a value, then the value isn't of type T?

Less obvious but possibly more important is that such a declaration subverts the point of type checking. Mistakes like this will no longer be caught:

let nums = [0, 1, 2]; // array of numbers
numbers.has(nums); // oops, no error!

So I wouldn't want to see this added to the standard libraries.

If these objections don't sway you and you still find this change useful for your own work, you could always modify or augment your local declaration of Set:

// put this in your own code to reap its benefits
interface Set<T> {
    has(elem: any): elem is T;
}

Cheers!

Duplicate of #13086

It's not a duplicate; #13086 is about performing a get() after a has(). This is... something else.

Joe Calzaretta (@jcalz)

Is there a very compelling scenario for this? I get the idea, but like Joe Calzaretta (@jcalz) said, this means you could easily screw up and pass anything accidentally which lead to some frustrating behavior.

There's nothing super wrong with adding your own overload if you feel it'd help you out a lot.

Wouldn't the narrower use-case, where has is just used just as non-undefined typeguard, still be really useful? I often have situations along the lines of:

function foo(map: Map<String, String>, key: String): String {
  if (map.has(key)) {
    return map.get(key); // Type 'String | undefined' is not assignable to type 'String'.
  }
  return "";
}

It feels odd and incomplete that TypeScript doesn't know that map.get(key) in the if's clause must return not-undefined thanks to that has.

Ahmed Fasih (@fasiha)

Ahmed Fasih (@fasiha) you are looking for #13086

Joe Calzaretta (@jcalz)

Agree with Joe Calzaretta (@jcalz) this doesn't seem like a good solution (to say nothing of the problem)

Joe Calzaretta (@jcalz)

interface Set<T> {
    has<U extends T>(elem: U): elem is U;
    has(elem: any): boolean; // wider case passes through
}

Wouldn't this prevent the else case problem that Joe Calzaretta (@jcalz) is describing?

Edit: I actually tested it and it prevents wider type narrowing, but it also causes the narrow type to resolve to never in the else case.

declare let numbers: Set<number>
declare let value: boolean | number
declare let value2: number

if (numbers.has(value)) {
  value + 2 // no narrowing
} else {
  value.charAt(0)  // no narrowing
}
if (numbers.has(value2)) {
  value2 + 2 // number as is.
} else {
  value2.charAt(0) // narrowed to never
}

Navigation Menu

Repository navigation

SUGGESTION: Set and Map '.has' method as type guard #18781

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

SUGGESTION: Set and Map '.has' method as type guard #18781

Description

Activity

jcalz commented on Sep 27, 2017

mhegazy commented on Sep 28, 2017

jcalz commented on Sep 28, 2017

DanielRosenwasser commented on Sep 28, 2017

fasiha commented on Aug 9, 2018

jcalz commented on Aug 9, 2018

RyanCavanaugh commented on Aug 13, 2018

avin-kavish commented on Aug 24, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions