reconsider the return type for set operations

[lonnen]

Matklad suggests intersection, union, and other set operations should return (&T, usize) instead of just &T.

de16931#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R887

[lonnen]

Here's some prior art. I'm considering some popular and some interesting languages, libraries where there is no stdlib support. To my suprise, many implementations of multiset don't appear to implement set operations at all and instead actually implement counters, dictionaries, or maybe just is_subset.

Languages that return [&T] or similar:

• mathematical notation
• ruby
• python
• js mnemonist lib returns iterator<&t>
• clojure achim multiset lib
• c++ operates over sorted collections, storing and returning multiple times

languages that return (&t count) or similar:

• go soniakeys lib is recommended in High Performance Go, but hasn't been updated in years. In a quick search, I couldn't find any other Go library that actually implemented set ops

languages that return Multiset:

• Haskell

languages thet implement subset, but not union, intersect, etc.:

• r set6 mathematical multiset lib. There are several libs that implement bits of set functionality, and convention seems to expected a sorted iterable to ducktype as a multiset
• swift implements counters

could not find:

• c# or any .net
• php

[lonnen]

A couple notes as I reconsider this --

• Languages that return [&T] tend to be less-strongly-typed than rust.
• Mathematical notation is not best understood as [&T] but as Multiset literals, making it closer to Haskell than the others
• Haskell's implementation is tree backed while mset mirrors the rust stdlib collections and uses HashMap, which uses Hashbrown, which is a rust implementation of Swiss Tables
• Haskell's implementation may be more sensible given Rust's type system, despite the popularity of other interfaces in other languages