This amendment is to add a new method, inverse(), to the CollectionDifference type. The diff to the previous proposal can be found here.
Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via email or direct message on the forums. If you send me email, please put "SE-0240" somewhere in the subject line.
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
No. inverse() is a noun (the inverse of the difference), not an imperative verb. inverted() is also an option, but both are valid per the naming guidelines.
No, swift library not need this algorithm implementation. Swift should be so lightweight as possible. Diff implementation is not so widely used as, for example, sorting algorithms of collections. IMO, swift library is helper for algorithm implementations, not the implementations directly.
This diff implementation should be somewhere in "Swift Foundation" or in another apple-maintained swift package.
I used other libraries with similar feature
In-depth study, I wrote my own swift implementation of this
To me, āinverseā feeling more mathy is exactly why itās a more appropriate name for this than āinvertedā. Itās a term of art. Just like an inverse mathematical function or an inverse matrix, an inverse diff is used to undo the original diff.
That could be a discussion in and of itself, but a "term of art" has inherent tradeoffs. It's saying there isn't a descriptive word in the popular vernacular, so we have to use a word that is less popular to describe something specific to a single domain that won't have a relevant meaning to laymen.
For people familiar with that domain, it feels natural. To anyone else, it feels foreign. e.g.
Great if you're familiar with those mathematical concepts, useless if you're not.
Given Swift's focus on approachability and education, when terms are synonyms, IMO the choice should lean towards the term with a more general usage.
But this is well into the bike-shedding territory so it's definitely not worth losing sleep over either way
But the word in more general use, āinvertedā, doesn't really have the right meaning when used in its common sense. So perhaps that is only more confusing than using a word that some may be unfamiliar with initially. As you said yourself:
If you're in Jr. High, come from a place without that level of education readily available, or just don't like math, then yes.
To be clear my point isn't that terms that requires explanation/education should never be used, but that when there is a clear more approachable alternative, that alternative should be used.
The term you so strenuously protest is the one you can find on wikipedia, because it happens to be the correct one. A CollectionDifference represents a function; the extension on RRC that uses it is called applying, consistent with a function. No matter what, the transformation that cancels it out is, well, an inverse function.
Anyway, if you're in junior high or in a place with no education and you get to the point where you're using collection diffing, you're probably eager to learn. Something that helps people who are eager to learn is using correct terminology. "inverse" isn't crazy jargon.
To be clear...as previously stated this is bike shedding and a pretty small issue, so I'm dropping it after this.
I never said it was.
If this was a mathematical API, it's use in math would make it the preferred term. This is not for mathematicians. This is a generalized API for use in working with Collections
If your background is in math (or you just like it), that term may make more sense because it's already familiar. My point is I think people outside of that realm rarely see/hear that term used, so it has little relevance to their existing experience.
IMO preferring mathematical terms over more generally used terms hurts a language's approachability and interest from people who aren't already in that domain. This would be far from the worst offender, but I think it's still relevant.
This is going to earn me ten years in bikeshedding + wikilawyering purgatory; nevertheless...
inverse is a noun, but more specifically, it's a participle of the verb invert. If the stdlib were to provide both mutating and nonmutating versions of this operation, the naming guidelines would fairly unambiguously require that they be called invert() and inverted():
When the operation is naturally described by a verb , use the verbās imperative for the mutating method and apply the āedā or āingā suffix to name its nonmutating counterpart. [boldface original]
In this case, I don't think it really matters that no invert() method will be provided. The product is still the result of applying the operation invert, so the "naturally described by a verb" rules should apply.
I agree that inverse is more consistent with math terminology. But consistency with the language's own specific naming guidelines is more important than consistency with abstract algebra, especially in a case like this where the options are close to being interchangeable from a linguistic standpoint.
The issue I see with inverted() is that the word āinvertedā has at least two uses: the mathematical one that we are discussing here, and a colloquial one that means something akin to āflipped upside down.ā In order for users to understand the actual meaning of the function, they must already understand what an inverse is, so I donāt buy that inverted() is a more understandable name than inverse(). Itās only āmore generally usedā because there are multiple meanings which do not coincide with the actual operation that the function performs. inverse() does not suffer from the same dual meaning issue, so itās better in that sense.
adding the 
