[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution

Ricardo Parada rparada at mac.com
Mon Feb 15 19:59:25 CST 2016

Hi Tony,

Is “inverted" a well known term for sets? 

If the default argument is a problem for protocols then perhaps this alternative:

Non-mutable (noun-based)

let union = 			a.union(b)
let intersection = 		a.intersection(b)
let difference = 		a.difference(b)
let symmetricDifference = 	a.symmetricDifference(b)	// alternative 1
let symmetricDifference =	a.intersectionComplement(b)	// alternative 2
let symmetricDifference = 	a.unionWithoutIntersection(b)	// alternative 3
let symmetricDifference = 	a.unionMinusIntersection(b)	// atternative 4

Mutable (verb-based)

set.merge(membersIn: someSet)			// union in-place
set.remove(membersNotIn: someSet)		// intersection in-place
set.remove(membersIn: someSet)			// difference in-place
set.merge(membersRemovingIntersection: someSet)	// symmetric difference in-place

I considered and discarded all the following for symmetric difference in-place:

set.merge(membersWithIntersectionRemoved: someSet)	// Not clear in my opinion
set.merge(membersRemovingIntersectionWith: someSet)	// The With seems not necessary
set.merge(removingMembersInCommonWith: someSet)		// Two verbs next to each other?
set.merge(allMembersRemovingIntersectionWith: someSet)	// Long and not more clear
set.merge(allRemovingMembersInCommon: someSet)		// All what?
set.merge(allMembersRemovingIntersection: someSet)	// Clear but longer
set.merge(membersRemovingIntersectionWith: someSet)	// With not necessary

> On Feb 14, 2016, at 7:35 PM, Tony Parker <anthony.parker at apple.com> wrote:
> Hi Ricardo,
> Your idea for exclusiveOr as a default arg had a lot of appeal to me at first, but when I went to go try it I realized that it doesn’t appear to be possible to enforce a value for a default argument in a protocol (which is the root of the API we’re talking about, in SetAlgebraType).
> All adopters of the protocol would be required to provide the default value in their implementation. It’s less than ideal to me to have each type that adopts the protocol decide what the default is, because a mistake would lead to confusing behavior:
> var s1 = /// … some kind of SetAlgebraType, where func merge(other: Self, removingMembersInCommon: Bool  = true)
> var s2 = /// … some other kind of SetAlgebraType, where func merge(other: Self, removingMembersInCommon: Bool  = false)
> s1.merge(s2) // xor
> s2.merge(s1) // union
> It is possible to set the default in a protocol extension, but both union and exclusiveOr are abstract in today’s SetAlgebraType.
> Of course the blame lies on the implementation of s1 here, but this approach does introduce a unique kind of sharp edge that we cannot warn about at compile time. I think that this is a consequence of putting something fundamental to the behavior of the method into an argument instead of into the base name.
> Here is another idea that we are considering:
> func intersected(other: Self) -> Self // was: intersect
> mutating func intersect(other: Self) // was: intersectInPlace
> func invertedIntersection(other: Self) -> Self // was: exclusiveOr
> mutating func invertIntersection(other: Self) // was: exclusiveOrInPlace
> - Tony
>> On Feb 14, 2016, at 2:36 PM, Ricardo Parada via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Hi David,
>> It had to read your code a few times to realize what you had changed. :-)  It's subtle and makes the names more consistent. I agree with your suggestion. 
>> As for whether or not the 'with' label should be removed from the mutable merge, I think it would work well either way.  However the code is more concise without it and still reads well. 
>> Ricardo Parada
>> On Feb 14, 2016, at 11:52 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> a.members(notIn: b)
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160215/98fd4152/attachment.html>

More information about the swift-evolution mailing list