right now, we represent std::set<T> and std::map<K,V> (and their multiX and unordered_X equivalents) as map[T]struct{} and map[K]V.
however, e.g.std::set<std::vector<T>> breaks this conversion: map[[]T]struct{} isn't a valid Go type ([]T isn't hashable).
same issue for, say, std::map<std::vector<T>, V>.
there are 2 use cases:
read a ROOT file produced with C++/pyroot and thus generate equivalent Go types to hold these data
write a ROOT file from groot (so with hopefully already valid Go types)
obviously, the latter isn't impacted by this issue.
to tackle the former, a possible avenue would be to implement dedicated types mimicking C++ semantics:
type Map[K, V any] struct { ... }
type Set[T any] struct { ... }
type MultiMap[K, V any] struct { ... }
type MultiSet[T any] struct { ... }
type UnorderedMap[K, V any] struct { ... }
type UnorderedSet[T any] struct { ... }
type UnorderedMultiMap[K, V any] struct { ... }
type UnorderedMultiSet[T any] struct { ... }
ultimately, this might be better resolved by implementing on-the-fly conversions between on-disk and in-memory representations:
right now, we represent
std::set<T>
andstd::map<K,V>
(and theirmultiX
andunordered_X
equivalents) asmap[T]struct{}
andmap[K]V
.however, e.g.
std::set<std::vector<T>>
breaks this conversion:map[[]T]struct{}
isn't a valid Go type ([]T
isn't hashable). same issue for, say,std::map<std::vector<T>, V>
.there are 2 use cases:
groot
(so with hopefully already valid Go types)obviously, the latter isn't impacted by this issue. to tackle the former, a possible avenue would be to implement dedicated types mimicking C++ semantics:
ultimately, this might be better resolved by implementing on-the-fly conversions between on-disk and in-memory representations:
set<T>
to/from[]T
map<K,V>
to/from[]pair[K,V]