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

[Dave Abrahams]

on Sun Feb 14 2016, Tony Parker <swift-evolution at swift.org> 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.

One good answer for that is that it's a language limitation that should
be fixed eventually and in the meantime shouldn't affect the way our Set
interface looks for all time.

There are other ways, e.g.

  extension Set : SetAlgebraType {} // missing conformance (already in the branch)
  var x: Set = [1, 4, 5]

  // #1
  extension SetAlgebraType {
    mutating func mergeRemovingMembersInCommon(other: Self) { 
      self.exclusiveOrInPlace(other) 
    }
  }
  x.mergeRemovingMembersInCommon([4, 6])

  // #2
  enum RemovingMembersInCommon { case removingMembersInCommon }
  extension SetAlgebraType {
    mutating func merge(other: Self, _: RemovingMembersInCommon) { 
      self.exclusiveOrInPlace(other) 
    }
  }
  x.merge([4, 6], .removingMembersInCommon)

  // #3
  extension SetAlgebraType {
    mutating func merge(other: Self, removingMembersInCommon: ()) { 
      self.exclusiveOrInPlace(other) 
    }
  }
  x.merge([4, 6], removingMembersInCommon: ())

These do create one more top-level method than one might otherwise see,
but it's debatable whether these two pieces of functionality should
ideally be funneled through a single method.

> 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

AFAICT, “inverting the intersection has the wrong sense;” it doesn't
imply anything about including elements not in the intersection in the
result.

> - Tony
>
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave