Pitch: ContainmentSet

[CTMacUser (Daryle Walker)]

@davedelong

Operators
ContainmentSet types are naturally usable with operators.

Union is expressible as concatenation (+) or logical-or (||)
Intersection is expressible using the logical-and operator (&&)
Subtraction is expressible using the subtraction operator (-)
Symmetric Difference is expressible using the exclusive-or operator (^)
Inversion is expressible using the prefix operators for negation (!) and bitwise-not (~)

Should the standard library provide implementations of these operators that work on ContainmentSets?

I think that the single "|" and "&" versions are better than the doubled versions. The doubled versions are very tied to Boolean OR and AND, especially since the default Swift versions copied C's short-circuit semantics. And short-circuit semantics wouldn't be appropriate here.

[mbrandonw (Brandon Williams)]

@CTMacUser

I think that the single “|” and “&” versions are better than the doubled versions. The doubled versions are very tied to Boolean OR and AND, especially since the default Swift versions copied C’s short-circuit semantics. And short-circuit semantics wouldn’t be appropriate here.

One thing to note is that the implementation of union and intersection on PredicateSet is to apply || and && pointwise:

extension PredicateSet {
  func union(_ other: PredicateSet) -> PredicateSet {
    return PredicateSet { self.contains($0) || other.contains($0) }
  }
}

So, in that sense, || and && are pretty appropriate for this operation. Though, it seems there are some pretty strong feelings against it from past discussions on SetAlgebra.

Also, written in this way you can see that PredicateSet gets all the short-circuiting benefits, so even those semantics are appropriate. For example:

let allInts = PredicateSet<Int> { _ in true }
let primes = PredicateSet<Int> { /* computation to determine if $0 is prime */ }

Doing allInts || primes completely short circuits the primality computation.

[davedelong]

Thanks for all the replies so far! I'm going to work up a newer version of the proposal this weekend and incorporate all your excellent feedback. I also am going to leave out the discussion on operators in the updated proposal as @Ben_Cohen and @xwu suggest. I don't think they need to be part of an initial implementation, and custom operators are contentious enough that I don't want to derail the discussion on functionality with detours about |, ||, and +.