Path to Stage 3

[bmeck]

• [x] Complete Spec Text
• [ ] Reviewers
  • [ ] TBD
  • [ ] TBD
• [ ] Editor Sign Off

Note: Removing *Set due to indefinite bike shedding seems the only path to Stage 3 according to previous meetings and offline communication.

[ljharb]

There remains a path forward with Set - namely, allow either key or value but throw if both are provided - but i think the last time we discussed it you weren’t on board with that compromise. It’s unclear if it would be viable to have Map without Set, for the same reasons the key/value question obstructed it for Set.

[bmeck]

Not going to bikeshed that here, split it out as per several previous discussions to allow Map to move forward. I do not agree that in this proposal we can move Set forward. We have had several discussions and I am not convinced that there is a path forward. Please create a follow on proposal or block this proposal. However, I will not be adding Set per conflicting demands preventing paths like you state above from being viable. Stating a single desired path is not a way to reach consensus and I do not see the demands of the parties involved as being resolvable. Without Set the Map API would still function as intended the only blocker there would be a demand for another API which as seen over several years of discussion is not viable.

[ljharb]

The thing that blocked this proposal last time was “map and set must be treated the same” - i fail to see how “just map” will get past that objection, but you’re of course welcome to attempt it.

[bmeck]

The thing that blocked this proposal last time was “map and set must be treated the same”

Kind of, the objection was that Map's argument needs to reusable Set's argument, and they must use key as the name (from @waldemarhorwat) to allow usability. However this had a counter-objection that it must not use key and must use value (from @bmeck) to keep consistency. This led to a proposal to allow either key or value exclusively to be the argument (from @ljharb ), but that prevent's Map from being reusable for Set which is what the change is for (@bmeck blocking due to conflict of invariant desired for @waldemarhorwat 's feedback). These constraints are unable to resolve as we have seen repeatedly.

I see Set's constraints unresolvable, yes; this is the claim to why that objection needs to be overridden. Stating that there is a resolution is simply not true given the constraints above.

[ljharb]

So, to be clear, you are blocking the compromise because of your interpretation of waldemar’s desired invariant, even though waldemar indicated that that compromise satisfies his invariant the last time we spoke?

[bmeck]

@ljharb I do not see it as a valid compromise. It violates the invariant desired that Map is reusable for Set. If we adopt that invariant/feedback the proposal of exclusively value or key does not follow it to my viewpoint (I can have views on the invariants we adopt even if they are not originating from myself). The key is that an invariant is being added and that the invariant does not allow for agreement amongst all parties. I'm trying to keep the invariant if we adopt it, but I cannot use that change and keep that invariant. The goal isn't to just ship something here for me, but to keep consistency and design goals.

[bmeck]

So, we have to drop the reusability invariant somehow. Dropping Set would accomplish this since there isn't a reuse to make the invariant from. Adding the invariant can be done at a latter time since Set can add a reusable argument.

[ljharb]

The desired invariant, as I understand it, is "i should be able to write code that deals with collection keys, or collection values, and it should be portable between Map and Set". I don't recall a desire expressed to be able to write Map/Set-portable code that deals with both, which is why the above compromise seemed promising.

[bmeck]

@ljharb Map's argument deals w/ both, so it cannot be exclusively one or the other and be reusable.

[bmeck]

I'm not arguing you can't write something that works in both, but that is true even if we used a different name for set components like element. If you had key, value, and element all in an object it would work in both and not face this conflict; however, alternative names were rejected upon not being able to be used in both locations under the same reference as arguments.