| 19:57 | <TabAtkins> | bakkot: I still feel it's weird for the receiver and argument to use different logic for how to access their values, but if this is a requirement, then the way the proposal is currently accessing the argument's data looks good. (I like in particular that it, incidentally, prevents accidentally passing a plain string and having it interpreted as a Set of letters.) |
| 19:58 | <TabAtkins> | The rest of the details seem fine too. My only complaint is still about the term 'difference' not suggesting directionality quite strongly enough (and symmetricDifference being just so long), but I expressed that in an issue a few years back and won't block if the champions ended up deciding it's okay. |
| 20:06 | <bakkot> | thanks for the review! |
| 20:08 | <bakkot> | yes, it basically ended up being a requirement that the receiver and argument need to use different logic for accessing their values |
| 20:08 | <bakkot> | and ack on the naming, but I think these names are the best we've got; symmetricDifference in particular doesn't come up very often and if you're reaching for it it you probably know it under that name |
| 20:26 | <TabAtkins> | Yeah, my only competing suggestions are to use .minus() and .difference() for the two of them - "minus" gives a correct directional read with "A minus B" meaning exactly what it sounds like. "difference" is more symmetric in English and can be used to indicate a symmetric difference - "what's the difference between A and B" is often symmetric. |
| 20:27 | <TabAtkins> | (I also consider "symmetry" to exceed the complexity budget for names I want to use in API design all by itself; its spelling isn't quite obvious.) |
| 20:29 | <bakkot> | using "difference" for symmetric difference would be very confusing, I think |
| 20:30 | <TabAtkins> | I think that was the pushback when I suggested it a few years ago, too. I disagree, but oh well. |