Sets and maps should have an extra
key option to extract keys from objects, to generalize lookup in case of non-unique objects and such. It'd also be useful for typed sets to ensure their values are coerced appropriately, and implementations could special-case sets with
key set to
String, and similar eagerly. (In particular,
BigInt sets don't actually need to store bigints internally for smaller values - they can just use a sparse bit set and upgrade only when they encounter a value too large to fit.) This would be purely internal, never exposed.
Also, if WebIDL interfaces with the
setlike<T> declaration are ever to be converted to native
Set subclasses, this functionality would be required for them as they'd 1. need to validate keys and 2. in many cases apply coercions (like
key: String) to them. And yes, this would be the minimal functionality required AFAICT as no platform object I'm aware of contains a
setlike<T> declaration and the only other restriction, that it needs to implement the interface directly, is something I strongly doubt would be necessary to keep.