Support invocation with no this

[bakkot]

It's nice to be able to treat functions like Set.from as actual functions which can be passed around, so that you can do stuff like let sets = [ [0, 1], [2, 3] ].map(Set.from). As currently spec'd this does not work because of the If IsConstructor(C) is false, throw a TypeError exception. step.

I think it would make sense to match the behavior of Array.from, which has the behavior of using the realm-default constructor for Array when the this value is not constructible. That way you get the subclassing behavior (where class MyMap extends Map {}; MyMap.of() instanceof MyMap /* true */;) while still allowing the functional-style invocation above.

[ljharb]

Although Promise.resolve and Promise.reject and friends fail to have this very useful fallback, I think it would be a mistake to repeat that omission on new statics like these.

[zloirock]

It conflicts with #13

Seems the answer is tc39/ecma262#544

[bakkot]

The language is currently inconsistent. I think Array.from both is a much stronger precedent and has better behavior than Promise.resolve.

[zloirock]

@bakkot by the link above you could find the explanation why Array.from precedent is not stronger. I like the idea of binding, but if guys who made the current built-ins subclassing conception against it...

[bakkot]

@zloirock The link above does not contain the claim that Array.from would be a weaker precedent than Promise.resolve for Map.from. (If it did, I'd disagree; Array.from is obviously much more relevant.) The closest it has is Allen speculating we may have been overzealous in giving Array.from its fallback.

I'd be curious to hear if @domenic still agrees with the position he expressed in that thread. Either way, though, I stand by the OP and my previous comment.

[bakkot]

Per discussion here and the next few days, I'm inclined to ignore the receiver entirely - i.e. no explicit affordances for subclassing. This is consistent with the set methods proposal (union, etc).