Set.has typing

[mbelsky]

lib Update Request

Missing / Incorrect Definition

The Set.has method's type expects that value type is typeof T:

https://github.com/microsoft/TypeScript/blob/master/src/lib/es2015.collection.d.ts#L43

And this definition makes safe-code uncompilable.

Sample Code

const set: Set<number> = new Set([1, 2, 3, 4])

set.has(5)
set.has('error?')
        ^^^^^^^ Argument of type 'string' is not assignable to parameter of type 'number'.

sandbox

Documentation Link

https://tc39.es/ecma262/#sec-set.prototype.has

---

Well what do you think about replacing this method definition with this:

    has(value: unknown): boolean;

[MartinJohns]

Checking the existence of a value that can't be present (according to the type system) should be an error. Why would you want it to be different?

In your local code you could just use 'error' as any.

[mbelsky]

I've came with this issue because now users need to add unnecessary type guards to make a safe operation in their code. An example:

const set: Set<number> = new Set([])

const list: unknown[] = [1, '2', {}]

list.map((item) => {
    if (typeof item === 'number') { // you don't need this type guard, but the code won't compile without that
        return set.has(item)
    }

    return false
})

[jgbpercy]

Right, well as Martin says, either do:

const set: Set<number> = new Set([])

const list: any[] = [1, '2', {}]

list.map((item) => {
    return set.has(item)
})

Or:

const set: Set<number> = new Set([])

const list: unknown[] = [1, '2', {}]

list.map((item) => {
    return set.has(item as any)
})

...if you want do something like your example code without adding any code that will be present at run time. Although if it were me I'd generally write the version with the type guard! unknown is a deliberately restrictive type that's designed to flag these sorts of things as errors if you're not asserting or guarding to a more specific type, any is designed to be permissive.

[RyanCavanaugh]

Ideally this would be a bivariant parameter; see #14520. Array#includes has the same problem.

The current behavior is the best available compromise. You're free to add the unknown overload to your code if you want to opt in to the less-specific version.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.