On Sat, Feb 6, 2021 at 7:28 AM Magnus Fromreide <magfr_at_[hidden]> wrote:
>
> On Fri, Feb 05, 2021 at 01:17:12PM -0500, Jason McKesson via Std-Proposals wrote:
> > 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?
>
> The problem I am trying to solve is when I have a number of data structures
> which I wish to look up with the timing characteristics of a set the key
> ain't the whole data structure and I want to be able to change the non-key
> parts of the value_type.

Save for the ability to change other parts of the value_type, all of
that can be achieved with a `set` as is (you can decide for yourself
which parts of the data structure are the "key" with your comparison
functor). So like I said, you want a non-`const` key type.

That's not a "tree"; it's just a non-`const` set.

Technically, you can achieve that by making all of the members of your
data structure that represent non-key information `mutable`. But
that's obviously cumbersome.