Ed/ing, InPlace, Set/SetAlgebra naming resolution


(Dave Abrahams) #1

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> to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,

···

--
-Dave


(Joe Groff) #2

-/// - `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

···

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> to the API of
SetAlgebra (and consequently Set) to make it conform to the guidelines
under development.

Comments welcome as usual,


(Erica Sadun) #3

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> 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


(Brent Royal-Gordon) #4

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> 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


(Xiaodi Wu) #5

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> 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> 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


(David Owens II) #6

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?

x.sort()
x.sort(inPlace: false)

x.add(y)
x.add(y, inPlace: false)

x.intersect(y)
x.intersect(y, inPlace: false)

Having to come up with all of these different word forms is confusing and the English language is terrible an consistency; we have no real chance here.

-David

···

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> 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


(Radek Pietruszewski) #7

-1 to the current diff.

`unioning`, `oring` really make me cringe. (O-ring? Let’s hope it’s not too cold outside.)

I also agree with Joe that the “with”s and “of”s are redundant. I really don’t see how they help explain the semantics of the method, or truly make anything clearer. Seems like an unnecessary attempt to make it sound like English, whether it’s useful or not.

— Radek

···

On 11 Feb 2016, at 17:52, 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> 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


(Ricardo Parada) #8

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.

···

On Feb 11, 2016, at 11: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> 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


(plx) #9

On a skim, if there’s a specific explanation as to *why* `inPlace` is a now a no-go, I don’t see it. 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)`).

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...).

···

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> 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


(Jacob Bandes-Storch) #10

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

Jacob

···

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.


(Erica Sadun) #11

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 <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


(James Hillhouse IV) #12

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'. 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> 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


(Xiaodi Wu) #13

I agree strongly with Craig that algebraic terms all strongly imply
that the operation is not in-place. Reductio ad absurdum: I don't
think very many people could stomach sin(x) being mutating.

···

On Thu, Feb 11, 2016 at 1: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.

Jacob

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


(Stephen Canon) #14

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

– Steve

···

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 <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.


(Dave Abrahams) #15

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.

http://english.stackexchange.com/questions/150843/verb-for-to-form-the-union-of-a-and-b

···

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

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> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Rob Mayoff) #16

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)

···

On Thu, Feb 11, 2016 at 12:54 PM, Jim Hillhouse via swift-evolution < 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'.


(Paul Cantrell) #17

I’ll also chime in with horror at “unioning.” Eew.

Mathematicians read A ∪ B as “A union B” — never “A union with B” or “A unioned with B” or anything else.

In short, the word “union” functions grammatically much like the word “plus.” The current proposal thus sounds as ridiculous as “a.plussing(with: b)”.

• • •

I agree with all those who’ve remarked on the uselessness of the “with:” for set operations.

• • •

On the part-of-speech aspect of this question:

This suggestion from Throsten makes the most sense, and feels the most natural — though it has the disadvantage that the add/union and subtract/difference correspondence is not immediately self-evident:

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

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

This suggestion from Erica makes lots of logical sense, but is a likely source of programmer error, because I (and I’m sure many others) would assume that a.union(b) is non-mutating:

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.

This one from Rob overcomes those problems, though “unite” feels like an affectation:

"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)

All these are superior to “unioning.”

Cheers, P

···

On Feb 11, 2016, at 10:49 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 11, 2016, at 3:27 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 11, 2016, at 3:46 PM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

-1 to the current diff.

`unioning`, `oring` really make me cringe. (O-ring? Let’s hope it’s not too cold outside.)

I also agree with Joe that the “with”s and “of”s are redundant. I really don’t see how they help explain the semantics of the method, or truly make anything clearer. Seems like an unnecessary attempt to make it sound like English, whether it’s useful or not.

— Radek

On 11 Feb 2016, at 17:52, 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> 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


(Xiaodi Wu) #18

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.

I could live with that.

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

Nit: the set difference, or just difference, of two sets is the term
for the result of subtraction() and isn't the same as the symmetric
difference.

···

On Thu, Feb 11, 2016 at 5:24 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:


(James Hillhouse IV) #19

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.

https://en.wiktionary.org/wiki/union#English
https://en.wiktionary.org/wiki/unioning

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’. 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.

http://english.stackexchange.com/questions/150843/verb-for-to-form-the-union-of-a-and-b

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> 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


(Stephen Canon) #20

While there’s a straightforward line of reasoning that led to this point, anyone who doesn’t know the history will be completely baffled when they come across:

  x.differ(y)

in source. Even knowing the history, it’s awkward.

This really needs to be either “xor” or “symmetricDifference” to be understandable. “symmetricDifferenceInPlace” gets to be a bit ridiculous, so I’d prefer “xor[InPlace]”. “xor” is sufficiently widely-used to qualify as a term-of-art; it’s the easiest-to-read unambiguous name for this operation.

– Steve

···

On Feb 11, 2016, at 6:24 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

  exclusiveOrInPlace -> differ