Date: Wed, 3 Jan 2024 15:02:26 -0500
On Wed, Jan 3, 2024 at 2:48 PM organicoman via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hello Gents,
> I would like to suggest a new data structure that combines 'std::unordered_set' and a 'std::stack' behavior.
> I will refere to it as 'std::hashed_stack'.
>
> Important methods of 'std::hashed_stack' container are:
>
> -'push': to insert a key, and if it already exists nothing will happen.
>
> -'pop': to extract the last key inserted.
But not the last key *pushed* if it was already in the container? That
sounds *really* weird. What's the use case for this data structure?
In fact, I'm not sure when I would want either behavior. If I'm using
a thing that calls itself a "stack," the idea that `push` and `pop`
should be balanced is non-negotiable. That's what makes it a *stack*.
The possibility that pushing two things and poping once could result
in a balanced stack is... bizarre.
If I push a thing twice, I should have to pop it twice, even if it's
the same thing and takes up the same space in the stack's storage.
<std-proposals_at_[hidden]> wrote:
>
> Hello Gents,
> I would like to suggest a new data structure that combines 'std::unordered_set' and a 'std::stack' behavior.
> I will refere to it as 'std::hashed_stack'.
>
> Important methods of 'std::hashed_stack' container are:
>
> -'push': to insert a key, and if it already exists nothing will happen.
>
> -'pop': to extract the last key inserted.
But not the last key *pushed* if it was already in the container? That
sounds *really* weird. What's the use case for this data structure?
In fact, I'm not sure when I would want either behavior. If I'm using
a thing that calls itself a "stack," the idea that `push` and `pop`
should be balanced is non-negotiable. That's what makes it a *stack*.
The possibility that pushing two things and poping once could result
in a balanced stack is... bizarre.
If I push a thing twice, I should have to pop it twice, even if it's
the same thing and takes up the same space in the stack's storage.
Received on 2024-01-03 20:02:38