On Oct 23, 2019, at 23:47, Inada Naoki <songofacandy@gmail.com> wrote:
But if we use + for dict merging, I think we should add + to set too. Then the set has `.union()`, `|` and `+` for the same behavior.
I don’t think we really need that. If set and dict have only a tiny bit of overlap in their API today (beyond both being sized iterable containers), as is the case today, then the fact that dict spells an operation + and set spells a similar but not identical operation | doesn’t seem like it’s going to be a serious learning hurdle. On the other hand, I don’t think it would be terrible to add it either. It’s no worse than C++ and a bunch of other languages having separate merge and union operations for the benefit of multisets, even though they do the exact same thing on sets, and nobody gets confused by that, even people who’ve never seen a multiset. (Sure, people ask why they both exist on StackOverflow, but nobody asks how to understand some code because ir used one instead of the other.) Which means we could add + to dict today, and if we later decide to add all the set operators to dict, so we have + and | do the same thing on dict, and then we also add + to set (which will be a lot more compelling than it is now)… no big deal. So, I no longer have any objection to + on dict based on the fact that we’re apparently considering also considering adding set operations later. I still like | more than +, but I no longer have a good argument for it, and I could live with either.