Added missing explicitly named operator equivalents

[regexident]

With this PR operators now are strictly forwarding functions.

Once https://github.com/mattt/Surge/pull/105 is merged I'll do a rebase and add unit tests for the remaining inout/…inPlace functions.

[mattt]

Providing in-place variants for these operations is a great idea. The only concern I have is that the use of ___InPlace may pollute the top-level namespace unnecessarily. Instead of that suffix, what do you think of a spelling that overloads these with the regular versions of these functions? For example, public func add<L: UnsafeMutableMemoryAccessible, R: UnsafeMemoryAccessible>(_ lhs: inout L, _ rhs: R)? Would that work, or am I missing something obvious about UnsafeMutableMemoryAccessible that makes this approach untenable?

[regexident]

I used …InPlace to prevent subtle bugs introduced by accidentally mixing up producing with mutating variants and also to make the code explicit.

Just like we have + and += and not just +.

Other prior art:

	Producing	Mutating
n/a	+	+=
Ruby	add	add!
Rust	add	add_assign
Swift	subtracting	subtract

[regexident]

As I understand it this PR is blocking the others, right?

Calling things adding (aka +) and add (+=) would be most fitting for Swift's naming scheme, but with + already being add, etc this ship has sailed, I fear.

[mattt]

(Really sorry for dropping the ball on this thread. I finally have another chance to work on this.)

@regexident Yeah, I made the wrong choice when I originally named the APIs (though to be fair, it predates the Swift API Design Guidelines). While it'd be idea for us to adopt a consistent add/adding for mutable / immutable pairs, I think stare decisis — not changing the underlying semantics of existing calls — wins out over idealism.

Maybe we can revisit this with the next major version, but these changes are fine for now.

The only other idea I might offer at this point is, maybe we can sidestep the issue by making the named functions themselves private? I don't know what kind of demand there is for addInPlace to begin with, but if it's addition is primarily in support of the assignment operators, then is there a strong compelling reason to export addInPlace in addition to .+=?

[regexident]

Maybe we can revisit this with the next major version, but these changes are fine for now.

The only other idea I might offer at this point is, maybe we can sidestep the issue by making the named functions themselves private? I don't know what kind of demand there is for addInPlace to begin with, but if it's addition is primarily in support of the assignment operators, then is there a strong compelling reason to export addInPlace in addition to .+=?

This sounds like a good compromise to me! 👍

I'll make them private internal and then we can see if there's demand. I'll update the inventory accordingly.