Adding sets with same content to a parent set. about golang-set

[ashkang]

I investigated the issue a bit and found the underlaying problem which in turn raises several different issues. The problem arises from the fact that we keep a pointer in our underlaying map structure for every Set when we call for example parent.Add(s1) when s1 is a Set, thus Add() over threadUnsafeSet cannot possibly distinguish between these two same and equal sets passed to it as they have different memory addresses. Now, here comes the interesting part. What do you expect from the outcome of the following code?

a := NewThreadUnsafeSet()
b := NewThreadUnsafeSet()

a.Add(1)
a.Add(2)

b.Add(a)
b.Add(2)

fmt.Println(b)
a.Add(3)
fmt.Println(b)

Here is the output:

Set{Set{1, 2}, 2}
Set{Set{2, 3, 1}, 2}

Interestingly, after adding 3 to set a, although invisibe to the eyes of the programmer, b changes which in my humble opinion is not a good scenario to happen here as you do not possibly expect from mapset to keep references to temporary objects in your code. We did nothing to b to expect a change in it's elements. One might possibly (and that is very likely to happen) decides to say reuse a set, change it or destroy it altogether in which case every set that temporary object has been added to gets corrupted. I think making a copy from the object that we're tying to add to our set and adding that copy is the only viable solution here. What do we do?

[NathanZook]

This looks to me like a potentially deep conflict. Go does not like to use containers as keys to maps.
Maps are containers, so if we use a map as a key....
I actually dug into this package to see exactly how this problem is being addressed. :(

It seems to me that the only real option is to use pointers for all structs, maps, arrays, and pointers. Comparison between these items is then required to be deep.

As for the a & b sets above, the paradox exists only because of appearances. The set b contains the set a. The display of a changes because a changes, but b continues to include a. Note that an additional set c, containing a and 2, is equal to b both before and after a is modified.

[deckarep]

This boils down to the fact that keys MUST be comparable types which is limited in Go to simple value types and struct types that don’t contain reference types themselves...ie, they only contain value types or further embed structs which only contain value types.

So the feature request isn’t easily supported in Go given this implementation. I’m going to say this is a fair trade off since the built-in types have the same limitations when it comes to keys and the nature of comparison.