[swift-evolution] SetAlgebra naming update

[Thorsten Seitz]

> Am 31.03.2016 um 19:53 schrieb Dave Abrahams <dabrahams at apple.com>:
> 
> 
>> 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.

Thanks! That's a very good example!

-Thorsten 

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