On Fri, Feb 05, 2021 at 07:32:55PM +0100, Marcin Jaczewski via Std-Proposals wrote:
> pt., 5 lut 2021 o 19:17 Jason McKesson via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
> >
> > On Fri, Feb 5, 2021 at 1:09 PM Magnus Fromreide via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >
> > You should instead focus on explaining why you want a tree that isn't
> > a set/map. Your post here just sort of assumes that this is a thing
> > that is desired. I mean, you say that it "gives a lot more flexibility
> > in the choice of the key_type", but you don't explain what you're
> > supposed to do with that flexibility. That is, when do you need it?
> > What problems can be better solved with the feature than without it?
> >
>
> If I understand correctly, the goal is to have set like class that has
> a deterministically computed key,
> but this key is not included in this class directly.
>
> Probaby 20y ago I would support a type like this but currently if we
> should add something like this it probably should be a "flat" tree.
> Because memory indirections are performance killers.

The flat_ property is orthogonal to this, one could easily extend
this to a flat_tree since the regular/unordered_/flat_ property is
about how the data is stored but I only talk about how you get the keys
of the values.

> Btw type like this could have interesting property. We could allow
> transferring nodes between different collections,
> even if they use different keys but have same value type.

Interesting idea!

/MF