[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution
anthony.parker at apple.com
Sun Feb 14 18:35:25 CST 2016
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
> On Feb 14, 2016, at 2:36 PM, Ricardo Parada via swift-evolution <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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution