Ed/ing, InPlace, Set/SetAlgebra naming resolution

Evolution Discussion
21

"intersection should form a pair with „union“, both being a noun.

"unioning“ is a bad choice. AFAIK „union“ is only rarely used as verb, so its present participle just sounds … strange.

I’d like to repeat my suggestion:

mutating (verbs):
x.intersect(x)
x.add(x)
x.subtract(x)

nonmutating (nouns):
x.intersection(x)
x.union(x)
x.difference(x)

-Thorsten

···

Am 11.02.2016 um 19:06 schrieb Joe Groff via swift-evolution <swift-evolution@swift.org>:

On Feb 11, 2016, at 8:52 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

-/// - `x.intersect(x) == x`
-/// - `x.intersect() == `
-/// - `x.union(x) == x`
-/// - `x.union() == x`
+/// - `x.intersection(with: x) == x`
+/// - `x.intersection(with: ) == `
+/// - `x.unioning(with: x) == x`
+/// - `x.unioning(with: ) == x`

What's with the (with:)? That seems like a pretty needless word. Same with 'of:' and friends.

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

22

inplace, or not, fundamentally affects the operation, including the return type. On a struct, it is the different between the method being mutating or not.

-Chris

···

On Feb 11, 2016, at 10:28 PM, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

I don’t know if this has been suggested already… but why not just use the same name and have an `inPlace` parameter with a default value?

23

All algebraic terms actually infer not in place. I don’t know of any algebra functions that mutates in place (at least not on the chalk board).

I would actually prefer algebraic terms such as union and intersection be reserved for immutable only.

union is the state of being united (i.e. past-tense).

Is unioning even a word?

···

On 2016-02-12, at 1:09:43, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

MHO: +1 on the intention of using less unwieldy names, but -1 on the specific solution. I fear that the current solution has some inexplicable inconsistencies and some Englishing which verges, again MHO, on Hungarianisms that others have mentioned are to be explicitly avoided.

For example, why is it intersection() but unioning()? Surely it should be either intersecting() and unioning() or intersection() and union()? Also, I understand that there's precedent elsewhere and that uniting() is not a good counterpart to union(), but unioning() is a pretty unsavory mangling of the noun. And then we have exclusiveOring(), which is just not English.

Could I propose an alternative that just came to mind? Reading about set algebra methods called to mind math class way back when. We'd say things like "take the derivative," "take the union," etc., which seems to me to imply an operation that is not in-place. "Take" is almost as short as "-ion" and "-ing" and might be more universally usable without mangling words: takeUnion(), takeExclusiveOr(), etc. It also has the advantage of calling to mind "make", which implies something constructor-like and thus not in-place.
On Thu, Feb 11, 2016 at 11:38 AM Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

24

The present participle of 'union' is technically speaking, 'unioning'.
But it is not widely used. In fact, in both Pages and Word, 'unioning' is
flagged as a misspelling of 'union'.

Outside of programming, "union" is a noun, not a verb, and "unite" is
already a perfectly good verb that means "create the union of". So why not

    func union(with other: Self) -> Self
    func unite(with other: Self)

My biggest problem with this diff is the different treatment of "union" and
"intersection"... it is confusing that one is mutating and the other is
non-mutating. They are both the same part of speech and both the term of
art, so they should both have the same mutability implications.

I'd vote either of the following (leaning toward the first group because I
think the term of art implies non-mutating):

func union(other: Self) -> Self
func unite(other: Self)
func intersection(other: Self) -> Self
func intersect(other: Self)

func uniting(other: Self) -> Self
func union(other: Self)
func intersecting(other: Self) -> Self
func intersection(other: Self)

unite and uniting are still reasonably close to union (exactly the same for
the first 3 characters which should help with autocomplete discoverability).

···

On Thu, Feb 11, 2016 at 4:27 PM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote:

On Thu, Feb 11, 2016 at 12:54 PM, Jim Hillhouse via swift-evolution < > swift-evolution@swift.org> wrote:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

25

I beg to disagree with your reasoning.
I think "union" is more commonly used as a noun and "intersection" certainly is not a verb. Your example sounded weird for me (but maybe that's because I'm not a native speaker) and I would rather expect the question to be "What is the union of A and B?"

-Thorsten

···

Am 11.02.2016 um 20:09 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:

My expectations is that the standard operators act upon a set, changing the set.

set1.union(with: set2) tells set1 to perform the union.
set1.unioned(with: set2) creates a new instance where set1 has been unioned with set 2.

Naming: intersected, unioned, and exclusiveOred over intersecting, unioning, exclusiveOring.
Mutating: union, intersection, exclusiveOr.
Non-Mutating, returning new value: unioned(with), intersected(with), exclusiveOred(with)

Reasoning:

* I think the -ing endings sound unnatural, stilted, and unmathematical. They make me wince.
* I think you have the nature of the words mis-assigned. In my opinion in this rare case, union, intersection, and exclusiveOr act as verbs as they are mathematical set operations. For example, "what is the result of A union B?" is a reasonable thing to say to a math person or put on an exam question, etc.

Importantly, they produce significant side effects, and should be treated as verbs that operate upon the receiver, updating the receiver, establishing their use for mutating ops.

Dave wrote:

- use nouns for methods with no side effects (or only incidental ones, like logging)
- use verbs for methods with significant side-effects

-- E

On Feb 11, 2016, at 9:52 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

26

Using only the operators | & - ^ |= &= -= ^= for the operations on Set would simplify the code and resolve the problem of the names of these functions. Set do not really need these functions as method, only the operators would be enough, like the BitwiseOperationsType which do not have the methods xor and orInPlace ...

With the operators, the question of "does this function mutate?" would not be anymore. The code would get clarity and brevity without problem of naming. Isn’t that the API Design Guidelines?

···

--
Sébastien

Le 12 févr. 2016 à 00:24, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> a écrit :

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

My suggestions:

  union -> union
  intersect -> intersection
  subtract -> subtraction

  unionInPlace -> unite
  intersectInPlace -> intersect
  subtractInPlace -> subtract

In other words, treat the mutating forms as imperative verbs and the nonmutating forms as nouns. This basically makes the nonmutating forms into accessors, which I think is a good alternative given the trouble we're having with -ing/-ed.

That still leaves exclusiveOr, which is frankly a horrible name to begin with. I think we have to derive a name from the "symmetric difference" terminology, giving us

  exclusiveOr -> difference
  exclusiveOrInPlace -> differ

However, given the difficulty we're having coming up with names, we might want to explore using operators instead.

  union -> |
  intersect -> &
  subtract -> -
  exclusiveOr -> ^

This gives us extremely straightforward mutating operators, of course, since we do have a convention for in-place operators:

  unionInPlace -> |=
  intersectInPlace -> &=
  subtract -> -=
  exclusiveOr -> ^=

Some things to like about these operators:

* They are not used for anything on sequences or collections, so they don't overload existing concepts like concatenation with incompatible semantics.
* They have the same commutativity and transitivity as the associated integer operations.
* The bitwise forms of `|` and `&` are already documented (in `_DisallowMixedSignArithmetic`) as the union and intersection of the bits, and `^` is documented in a compatible way. Meanwhile, `-` literally means "subtraction", the exact same operation we're exposing.
* And of course, it's just *nice* to not have to write long, unwieldy method names for fundamental operations.

Swift generally tries not to overload operators too much, but I think in this case, these overloads would be appropriate and helpful, while also getting us out of a sticky naming problem.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

27

I agree!

···

On Feb 11, 2016, at 4:27 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Feb 11, 2016 at 12:54 PM, Jim Hillhouse via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
The present participle of 'union' is technically speaking, 'unioning'. But it is not widely used. In fact, in both Pages and Word, 'unioning' is flagged as a misspelling of 'union'.

Outside of programming, "union" is a noun, not a verb, and "unite" is already a perfectly good verb that means "create the union of". So why not

    func union(with other: Self) -> Self
    func unite(with other: Self)

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

28

If we are going to force Set fit the naming guidelines, I would prefer
to stay away from the mathematical terms altogether.

   func insertingContentsOf(other: Self) -> Self // union
   mutating func insertContentsOf(other)

   func members(in other: Self) -> Self // intersection
   mutating func removeMembers(notIn: other)

   func removingMembersAndAddingNonMembers(in other: Self) -> Self // symmetric difference
   mutating func removeMembersAndAddingNonMembers(in other: Self)

   func removingMembers(in other: Self) -> Self // subtract
   mutating func removeMembers(in other: Self)

If it would help with clarity, we could replace "in" with "foundIn"
above.

···

on Fri Feb 12 2016, Ricardo Parada <swift-evolution@swift.org> wrote:

Hi all,

I can’t make up my mind. Let me propose two different alternatives
that I’m not sure if they have been considered:

ALTERNATIVE 1

Non-mutable (noun-based)

- func union(other: Self) -> Self
+ func union(other: Self) -> Self Assumes union is a noun, i.e. not a verb

- func intersect(other: Self) -> Self
+ func intersection(other: Self) -> Self

- func subtract(other: Self) -> Self
+ func subtraction(other: Self) -> Self

- func exclusiveOr(other: Self) -> Self
+ func symmetricSubtraction(other: Self) -> Self

Mutable (verb-based)

- mutating func unionInPlace(other: Self)
+ mutating func unite(other: Self)

- mutating func intersectInPlace(other: Self)
+ mutating func intersect(other: Self)

- mutating func subtractInPlace(other: Self)
+ mutating func subtract(other: Self)

- mutating func exclusiveOrInPlace(other: Self)
+ mutating func symmetricSubtract(other: Self)

Comments:

With this alternative we keep the union name which I assume is
popular. However, one has to accept unite as a verb (for the mutable
version) as I wanted all the mutable methods use verbs for
consistency. I think unite is acceptable because it can be found in
the dictionary and it is a verb.

Notice that all the non-mutable methods use nouns: union,
intersection, subtraction and symmetricSubtraction.

I understand some may oppose to symmetricSubtraction saying that
symmetricSubraction is not as common as "exclusive or". However,
using symmetricSubtraction is consistent with subtraction and it hints
to a variation of the “subtraction" operation. We will get used to it
quickly / easily.

The mutable methods all use verbs: unite, intersect, subtract and symmetricSubtract.

ALTERNATIVE 2

Non-mutable

- func union(other: Self) -> Self
+ func adding(other: Self) -> Self

- func intersect(other: Self) -> Self
+ func intersecting(other: Self) -> Self

- func exclusiveOr(other: Self) -> Self
+ func exclusiveOring(other: Self) -> Self

- func subtract(other: Self) -> Self
+ func removing(other: Self) -> Self

Mutable

- mutating func unionInPlace(other: Self)
+ mutating func add(other: Self)

- mutating func intersectInPlace(other: Self)
+ mutating func intersect(other: Self)

- mutating func exclusiveOrInPlace(other: Self)
+ mutating func exclusiveOr(other: Self)

- mutating func subtractInPlace(other: Self)
+ mutating func remove(other: Self)

Comments: This alternative gives up on union in favor or add. Many
may not like this, that is why I have it as the second alternative.
It brings back exclusiveOr and treats it as a verb. Some may argue
that exclusiveOr is a noun for the "exclusive or" operation.

--
-Dave

29

On a skim, if there’s a specific explanation as to *why* `inPlace` is
a now a no-go, I don’t see it.

Several justifications were given:

* Several people have an “ick” reaction when they see it.

* It's not in the guidelines.

* If we add it to the guidelines, it will only be as fallback
  last-resort alternative.

* If one of the three main collection types can't conform to the
  recommendations of the non-last-resort guidelines, the guidelines are
  a failure.

I can’t say I like the proposed changes
very much, and I definitely don’t like some of the more-creative
suggestions.

It’s hard to offer help when it’s not clear what was deemed
problematic about the existing (and “perfectly fine with me”!) names.

Separately, can I ask here why SetAlgebra protocol doesn’t contain an
*overridable* method like `func intersects(other: Self) -> Bool`?

(Note: I am *well-aware* that `a intersects b <=> !(a and b are disjoint)`).

There's no point in providing an override if there's no chance of it
being better than the default implementation.

That absence has been puzzling me ever whichever release of Swift
first introduced this protocol, particularly since e.g. both
`isSubsetOf` and `isSupersetOf` are individually-overridable.

(Likewise, but less so, I do wonder why the protocol doesn’t contain
*overridable* `isStrictSubset` and `isStrictSuperset` functions,
either...).

Same reasoning, but we may have mistakenly decided there was no chance
of optimization. If so, please open a ticket.

···

on Sat Feb 13 2016, plx <swift-evolution@swift.org> wrote:

On Feb 11, 2016, at 10:52 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

30

I was a fan of the inPlace variants because for me it was more clear than remembering sort from sorted.

Is there a reason for the mutating versions of these at all?

I would say that setA = setA.union(setB) is most expressive of intent. It makes it absolutely clear that setA is being replaced by something.

Having a mutating or non-mutating version of an operation but not both would be less confusing IMO.

Methods such as append() and remove() could still be mutating as there has never been non-mutating version of them. Or the suggested .= operator could be used and all of these methods could become non-mutating.

i.e.

setA .= union(setB)

arrayC .= elementToAdd

arrayD .= removeAll()

where A .= method() means A = A.method()

Daniel

···

On Feb 13, 2016, at 2:32 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Sat Feb 13 2016, plx <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On a skim, if there’s a specific explanation as to *why* `inPlace` is
a now a no-go, I don’t see it.

Several justifications were given:

* Several people have an “ick” reaction when they see it.

* It's not in the guidelines.

* If we add it to the guidelines, it will only be as fallback
last-resort alternative.

* If one of the three main collection types can't conform to the
recommendations of the non-last-resort guidelines, the guidelines are
a failure.

I can’t say I like the proposed changes
very much, and I definitely don’t like some of the more-creative
suggestions.

It’s hard to offer help when it’s not clear what was deemed
problematic about the existing (and “perfectly fine with me”!) names.

Separately, can I ask here why SetAlgebra protocol doesn’t contain an
*overridable* method like `func intersects(other: Self) -> Bool`?

(Note: I am *well-aware* that `a intersects b <=> !(a and b are disjoint)`).

There's no point in providing an override if there's no chance of it
being better than the default implementation.

That absence has been puzzling me ever whichever release of Swift
first introduced this protocol, particularly since e.g. both
`isSubsetOf` and `isSupersetOf` are individually-overridable.

(Likewise, but less so, I do wonder why the protocol doesn’t contain
*overridable* `isStrictSubset` and `isStrictSuperset` functions,
either...).

Same reasoning, but we may have mistakenly decided there was no chance
of optimization. If so, please open a ticket.

On Feb 11, 2016, at 10:52 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

31

On a skim, if there’s a specific explanation as to *why* `inPlace` is
a now a no-go, I don’t see it.

Several justifications were given:

* Several people have an “ick” reaction when they see it.

* It's not in the guidelines.

* If we add it to the guidelines, it will only be as fallback
last-resort alternative.

* If one of the three main collection types can't conform to the
recommendations of the non-last-resort guidelines, the guidelines are
a failure.

As a devil’s advocate, why wouldn’t the existing names be justifiable under “Use terminology well” guideline?

I’d consider making up new terminology for a well-established domain much worse than simply not following the naming conventions.

I can’t say I like the proposed changes
very much, and I definitely don’t like some of the more-creative
suggestions.

It’s hard to offer help when it’s not clear what was deemed
problematic about the existing (and “perfectly fine with me”!) names.

Separately, can I ask here why SetAlgebra protocol doesn’t contain an
*overridable* method like `func intersects(other: Self) -> Bool`?

(Note: I am *well-aware* that `a intersects b <=> !(a and b are disjoint)`).

There's no point in providing an override if there's no chance of it
being better than the default implementation.

But again, cf `isSupersetOf` and `isSubsetOf`...which are both overridable unless I’m misunderstanding. (Especially as there’s risk of a performance “gotcha” if you only override “the wrong one”).

That absence has been puzzling me ever whichever release of Swift
first introduced this protocol, particularly since e.g. both
`isSubsetOf` and `isSupersetOf` are individually-overridable.

(Likewise, but less so, I do wonder why the protocol doesn’t contain
*overridable* `isStrictSubset` and `isStrictSuperset` functions,
either...).

Same reasoning, but we may have mistakenly decided there was no chance
of optimization. If so, please open a ticket.

There are definitely examples of such; https://bugs.swift.org/browse/SR-735 .

After looking at what’s in github, there really ought to be a few more families of default implementations, e.g. `extension SetAlgebraType where Self:CollectionType` and `extension SetAlgebraType where Self:CollectionType, Index: RandomAccessIndexType` (where we can assume O(1) count).

Is that better as just a ticket or as a discussion on one of the lists?

···

On Feb 13, 2016, at 1:32 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Sat Feb 13 2016, plx <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 11, 2016, at 10:52 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

32

"intersected" sounds okay to me. "unioned" is borderline, and "ored" is not
something I'd want in the standard library. Neither is "oring".

···

On Thu, Feb 11, 2016 at 11:25 AM, Erica Sadun <erica@ericasadun.com> wrote:

I see the -ed versions as short for -edSet, with the Set being implied.
Under this reasoning, unioned == unionedSet, intersected == intersectedSet,
thus acting as nouns not verbs, and used for non-mutating application.

inPlace is only for mutating application. I mildly prefer the shorter
union to unionInPlace, although I could argue both sides. (The latter is
clearer but longer, the former is the short verb action that the whole
guideline thing is supposed to endorse.)

-- E

On Feb 11, 2016, at 12:19 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

On Thu, Feb 11, 2016 at 11:09 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

*Non-Mutating, returning new value*: unioned(with), intersected(with),
exclusiveOred(with)

Reasoning:

* *I think the -ing endings sound unnatural, stilted, and
unmathematical. *They make me wince.

So do the -ed versions, IMO. That's why -InPlace is such a convenient
suffix.

Jacob

33

I like Thorsten’s suggestion. I’m not an authority, but as far as I can tell, ‘add’ and ’subtract' are still mathematical correct and precise when used this way.

—CK

···

On Feb 11, 2016, at 10:49 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

"intersection should form a pair with „union“, both being a noun.

"unioning“ is a bad choice. AFAIK „union“ is only rarely used as verb, so its present participle just sounds … strange.

I’d like to repeat my suggestion:

mutating (verbs):
x.intersect(x)
x.add(x)
x.subtract(x)

nonmutating (nouns):
x.intersection(x)
x.union(x)
x.difference(x)

-Thorsten

Am 11.02.2016 um 19:06 schrieb Joe Groff via swift-evolution <swift-evolution@swift.org>:

On Feb 11, 2016, at 8:52 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

-/// - `x.intersect(x) == x`
-/// - `x.intersect() == `
-/// - `x.union(x) == x`
-/// - `x.union() == x`
+/// - `x.intersection(with: x) == x`
+/// - `x.intersection(with: ) == `
+/// - `x.unioning(with: x) == x`
+/// - `x.unioning(with: ) == x`

What's with the (with:)? That seems like a pretty needless word. Same with 'of:' and friends.

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

34

xor is a well known and widely used synonym. "symmetricDifference" not so much.

-- E

···

On Feb 11, 2016, at 12:22 PM, Stephen Canon <scanon@apple.com> wrote:

On Feb 11, 2016, at 2:19 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Feb 11, 2016 at 11:09 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Non-Mutating, returning new value: unioned(with), intersected(with), exclusiveOred(with)

Reasoning:

* I think the -ing endings sound unnatural, stilted, and unmathematical. They make me wince.

So do the -ed versions, IMO. That's why -InPlace is such a convenient suffix.

“exclusiveOr” is pretty awkward too. I would tend to call this either “xor” or “symmetricDifference”.

– Steve

35

Assuming one would want to avoid the -ed suffix (and also -ing), one might consider:

* intersectionOf(), orOf(), unionOf() (or "With" over "Of")
* setIntersection(), setOr(), setUnion(),
* intersectionResult(), orResult(), unionResult(),
etc

-- E

···

On Feb 11, 2016, at 12:28 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

"intersected" sounds okay to me. "unioned" is borderline, and "ored" is not something I'd want in the standard library. Neither is "oring".

On Thu, Feb 11, 2016 at 11:25 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
I see the -ed versions as short for -edSet, with the Set being implied. Under this reasoning, unioned == unionedSet, intersected == intersectedSet, thus acting as nouns not verbs, and used for non-mutating application.

inPlace is only for mutating application. I mildly prefer the shorter union to unionInPlace, although I could argue both sides. (The latter is clearer but longer, the former is the short verb action that the whole guideline thing is supposed to endorse.)

-- E

On Feb 11, 2016, at 12:19 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

On Thu, Feb 11, 2016 at 11:09 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Non-Mutating, returning new value: unioned(with), intersected(with), exclusiveOred(with)

Reasoning:

* I think the -ing endings sound unnatural, stilted, and unmathematical. They make me wince.

So do the -ed versions, IMO. That's why -InPlace is such a convenient suffix.

Jacob

36

'Symmetric difference' sounds weird to me too, but per Wikipedia, the
counterpart name to 'union' and 'intersection' for the result of a XOR
operation on a set would in fact be the 'symmetric difference,' with
apparently no alternative or more commonly used name:

* Union of the sets A and B, denoted A ∪ B, is the set of all objects that are a member of A, or B, or both. The union of {1, 2, 3} and {2, 3, 4} is the set {1, 2, 3, 4} .
* Intersection of the sets A and B, denoted A ∩ B, is the set of all objects that are members of both A and B. The intersection of {1, 2, 3} and {2, 3, 4} is the set {2, 3} .

...

···

* Symmetric difference of sets A and B, denoted A △ B or A ⊖ B, is the set of all objects that are a member of exactly one of A and B (elements which are in one of the sets, but not in both). For instance, for the sets {1,2,3} and {2,3,4} , the symmetric difference set is {1,4} . It is the set difference of the union and the intersection, (A ∪ B) \ (A ∩ B) or (A \ B) ∪ (B \ A).

On Thu, Feb 11, 2016 at 1:26 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

xor is a well known and widely used synonym. "symmetricDifference" not so
much.

-- E

On Feb 11, 2016, at 12:22 PM, Stephen Canon <scanon@apple.com> wrote:

On Feb 11, 2016, at 2:19 PM, Jacob Bandes-Storch via swift-evolution > <swift-evolution@swift.org> wrote:

On Thu, Feb 11, 2016 at 11:09 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

Non-Mutating, returning new value: unioned(with), intersected(with),
exclusiveOred(with)

Reasoning:

* I think the -ing endings sound unnatural, stilted, and unmathematical.
They make me wince.

So do the -ed versions, IMO. That's why -InPlace is such a convenient
suffix.

“exclusiveOr” is pretty awkward too. I would tend to call this either “xor”
or “symmetricDifference”.

– Steve

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

37

Yes, “symmetric difference” is the common name for this operation in Mathematics.
– Steve

···

On Feb 11, 2016, at 2:41 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

'Symmetric difference' sounds weird to me too, but per Wikipedia, the
counterpart name to 'union' and 'intersection' for the result of a XOR
operation on a set would in fact be the 'symmetric difference,' with
apparently no alternative or more commonly used name:

* Union of the sets A and B, denoted A ∪ B, is the set of all objects that are a member of A, or B, or both. The union of {1, 2, 3} and {2, 3, 4} is the set {1, 2, 3, 4} .
* Intersection of the sets A and B, denoted A ∩ B, is the set of all objects that are members of both A and B. The intersection of {1, 2, 3} and {2, 3, 4} is the set {2, 3} .

...

* Symmetric difference of sets A and B, denoted A △ B or A ⊖ B, is the set of all objects that are a member of exactly one of A and B (elements which are in one of the sets, but not in both). For instance, for the sets {1,2,3} and {2,3,4} , the symmetric difference set is {1,4} . It is the set difference of the union and the intersection, (A ∪ B) \ (A ∩ B) or (A \ B) ∪ (B \ A).

On Thu, Feb 11, 2016 at 1:26 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

xor is a well known and widely used synonym. "symmetricDifference" not so
much.

-- E

On Feb 11, 2016, at 12:22 PM, Stephen Canon <scanon@apple.com> wrote:

On Feb 11, 2016, at 2:19 PM, Jacob Bandes-Storch via swift-evolution >> <swift-evolution@swift.org> wrote:

On Thu, Feb 11, 2016 at 11:09 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote:

Non-Mutating, returning new value: unioned(with), intersected(with),
exclusiveOred(with)

Reasoning:

* I think the -ing endings sound unnatural, stilted, and unmathematical.
They make me wince.

So do the -ed versions, IMO. That's why -InPlace is such a convenient
suffix.

“exclusiveOr” is pretty awkward too. I would tend to call this either “xor”
or “symmetricDifference”.

– Steve

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

38

Nope. The verb is “unite”.

-jcr

···

On Feb 11, 2016, at 10:48 AM, Craig Cruden via swift-evolution <swift-evolution@swift.org> wrote:

Is unioning even a word?

39

Is unioning even a word?

Nope. The verb is “unite”.

If we don't like "unite", alternatives include "unify" and even "unionize".

···

--
Brent Royal-Gordon
Architechies

40

Dave, you are correct that in today’s common usage, ‘union’ is solely
a noun. And you’re right that nouns don’t have an anything-participle
or else ‘nationing’, ‘automobiling’, or ‘lift-offing' would be
naturally appropriate, which they are obviously not, at least not yet.

So, when I first saw ‘unioning’, my first thought was, “Huh”?

But lo and behold, if you go back to an older version of Webster’s,
apparently the 1917 edition if Wiktionary is to be believed, it turns
out that ‘union’ was both a noun and a verb and therefore at least in
that era’s usage had a past participle.

union - Wiktionary, the free dictionary
unioning - Wiktionary, the free dictionary

I'm just gonna smile now. :-)

The reason I commented on ‘union’ as a verb was because, with
‘unioning’ proposed in SetAlgebra, I figured someone in the Swift
group must have been a fan of older verb-form usage of ‘union’.

Yep, someone must've. ;-)

···

on Thu Feb 11 2016, James Hillhouse IV <swift-evolution@swift.org> wrote:

That’s what I get for basing my comment on ‘Wiki’-anything.

On Feb 11, 2016, at 5:05 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:

on Thu Feb 11 2016, Jim Hillhouse >> <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> >> wrote:

Are these function names being based on the present participle of each verb, e.g. 'union' and 'intersect'?

The present participle of 'union' is technically speaking,
'unioning'.

Technically speaking, I'm pretty sure you can't have a participle of
anything that isn't a verb, and “union” isn't one AFAICT.

single word requests - Verb for "to form the union of A and B" - English Language & Usage Stack Exchange
<single word requests - Verb for "to form the union of A and B" - English Language & Usage Stack Exchange;

But it is not widely used. In fact, in both Pages and Word, 'unioning'
is flagged as a misspelling of 'union'.

The present participle of 'intersect' is 'intersecting';
'intersection' is a noun.

As currently presented, the use of 'union' and 'intersection' are a
mixing of rarely used though correct present participle verb tense and
a noun. I think it would be better to recognize that 'union' and
'intersection' are two universally used mathematical terms and to
forego the suggested verb tense gymnastics.

Jim

jimhillhouse@me.com
512-484-9489

Sent from Jim's iPhone

On Feb 11, 2016, at 12:09 PM, Xiaodi Wu via swift-evolution >>>> <swift-evolution@swift.org> wrote:

MHO: +1 on the intention of using less unwieldy names, but -1 on the
specific solution. I fear that the current solution has some
inexplicable inconsistencies and some Englishing which verges, again
MHO, on Hungarianisms that others have mentioned are to be
explicitly avoided.

For example, why is it intersection() but unioning()? Surely it
should be either intersecting() and unioning() or intersection() and
union()? Also, I understand that there's precedent elsewhere and
that uniting() is not a good counterpart to union(), but unioning()
is a pretty unsavory mangling of the noun. And then we have
exclusiveOring(), which is just not English.

On Thu, Feb 11, 2016 at 11:38 AM Dave Abrahams via swift-evolution >>>>> <swift-evolution@swift.org> wrote:

Hi All,

The API guidelines working group took up the issue of the InPlace suffix
yesterday, and decided that it was not to be used anywhere in the
standard library. We are planning to apply the changes shown here
<https://gist.github.com/dabrahams/d872556291a3cb797bd5&gt; to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave