[swift-evolution] SetAlgebra naming update

Dave Abrahams dabrahams at apple.com
Thu Mar 31 12:53:52 CDT 2016

on Thu Mar 31 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:

> Am 30. März 2016 um 17:48 schrieb Dave Abrahams <dabrahams at apple.com>:
>     on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:
>                 Am 30.03.2016 um 16:49 schrieb Dave Abrahams <dabrahams at apple.com>:
>                         on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:
>                         That's certainly an improvement, but why "formIntersection" instead of
>                         "intersect" (in analogy to "subtract")?
>             1. Consistency with union, which is more closely related than subtract.
>     I'd prefer consistency with the verb rule here
>     Which rule is that? As far as I can tell, this is consistent with all
>     the rules.
> "Those with side-effects should read as imperative verb phrases"

“form <some-noun-phrase>” is an imperative verb phrase.

> I expect a common verb to be chosen over an awkward, constructed one,
> although I have to admit that the verb "intersect" is used only very
> seldom if at all in set theory or geometry.  Therefore you might have
> a point with "intersect" having the wrong implication, but see below.
>         (using formXXX only as last resort).
>     Though I prefer not to, you can look at this as a last resort if you
>     like; the alternative you're proposing has the wrong implication, so it
>     is not a candidate. It would be like using “remainder” as a verb for
>     integers. Yes, it's a legitimate verb, but it means the wrong thing
>     (see retail).
>                 2. "Intersect" actually has the wrong meaning as an imperative. If you
>             tell set A to intersect set B, and then ask whether A intersects B
>             (!A.isDisjoint(with: B)), you would expect an answer of true.
>     Sorry, but I do not agree. With that reasoning I would have to expect
>     a.intersection(b) to be not empty.
>     Yes, that's exactly what I'm saying. If you tell A to intersect B,
>     presumably when the call completes, A intersects B (i.e. has a non-empty
>     intersection). That would imply an implementation like, e.g.
> With a.intersection(b) I meant to extend your reasoning to the
> non-mutating method. 
> You surely do not expect the intersection of a and b to be non-empty
> when calling the non-mutating method? 

No I do not.

> Then why should you expect that in the mutating case?  

for the same reason that 


might return true or false but


has to change shape1 so it encloses shape2.

> Is it because the noun implies a current state whereas the verb should
> be read as a command demanding to create a certain state? (I'm not a
> native speaker, so please bear with me)

I think that's a pretty good explanation.



More information about the swift-evolution mailing list