If you took 100 random developers off the street, and showed them code that said:
About 99.5% of them would understand the second better than the first on first read.
The other 0.5 of a developer would be living somewhere near Boulder and growing
his own hemi-pharmaceuticals.
The problem with subtraction is that there isn't really a good noun/formNoun pair
for it. That means either breaking the pair into two words that aren't well matched
or using a noun that isn't that amazing, such as difference.
In all my attempts at trying to brainstorm up a better word that would (1) retain
the characteristics of mutating/non-mutating pairing while (2) being easy to read
and understand, I could not come up with better than Dave A's subtract/subtracting.
I may not like it aesthetically but when it comes to offering something better,
I've got nothing.
That said, I'd really like to see a Swift Doc markup that allows you to mark
pairs of mutating/nonmutating functions, not from a compiler point of
view but in doc markup.
/// - nonmutatingVersion:
/// - mutatingVersion:
What group handles expansion of the markup keywords and how can I file a
feature request asking for this to be added?
On Mar 28, 2016, at 6:19 PM, Dave via swift-evolution <email@example.com> wrote:
On Mar 25, 2016, at 4:45 PM, Dave Abrahams <firstname.lastname@example.org> wrote:
on Fri Mar 25 2016, davesweeris-AT-mac.com wrote:
Can we rename `subtract` to `complement`, since that’s the correct
term? At least, I’m assuming that’s what `subtract` means… if not, I’m
It's not just “complement,” because that means inverting set membership
of everything in a finite domain. It would have to be “relative
complement.” But “relative complement” lacks the directional
implication that plagues terms like “difference,” but not “subtracting.”
Fair points… I accidentally left off the argument label. May I amend my suggestion to "rename `subtract(:)` to `complement(relativeTo:)`”? It just seems to me that if we’re going to claim we’re implementing something, we should adopt as much of its “standard" syntax and terminology as possible. It makes Swift easier to use for those coming from other disciplines, IMHO.