[swift-evolution] SetAlgebra naming update

[Dave Abrahams]

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 

    shape1.encloses(shape2)

might return true or false but

    shape1.enclose(shape2)

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.

HTH,

-- 
Dave