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
-/// - `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,
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
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
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
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
-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
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
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
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.
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
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
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
“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.
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.
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-9489Sent 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
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'.
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
My suggestions:
union -> union
intersect -> intersection
subtract -> subtractionunionInPlace -> unite
intersectInPlace -> intersect
subtractInPlace -> subtractIn 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:
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.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-9489Sent 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
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