Date: Fri, 14 Apr 2023 13:51:12 -0400

On Fri, Apr 14, 2023 at 12:01 PM Jason McKesson via Std-Proposals <

std-proposals_at_[hidden]> wrote:

> On Fri, Apr 14, 2023 at 11:02 AM LoS via Std-Proposals

> <std-proposals_at_[hidden]> wrote:

> >

> > As suggested in a reply to my previous proposal, I drafted a proposal to

> introduce the std::is_uniqued() function.

> >

> > Since it was developed from Arthur's idea, I would be very happy if you

> took part in the proposal.

> >

> >

> > I. Motivation

> >

> > The std::is_uniqued() function can be used to check if a range of

> elements has no consecutive equal elements.

> >

> > Even if there is already the std::adjacent_find() function, that can be

> used to get the same effect, the introduction of the function

> std::is_uniqued makes the check clearer, like std::contains() and

> std::is_sorted() do.

>

> Is this a thing people want to do? `std::contains` is a thing that

> people sometimes need to do as a distinct action from `std::find`.

> What code needs to detect if a range has "consecutive equal elements"

> *without* also wanting to know where that element is?

>

I don't know about "needs," but we do use this primitive in the *invariant

assertions* of flat_set and flat_map. So at least possibly "wants."

https://github.com/Quuxplusone/llvm-project/blob/trivially-relocatable-v60/libcxx/include/__flat_set/flat_set.h#L1055-L1059

The main motivation here IMHO is simple symmetry. Consider that we already

have

- is_sorted_until (returns iterator), is_sorted (i.e. is_sorted_until ==

end())

- is_heap_until (returns iterator), is_heap (i.e. is_heap_until == end())

- adjacent_find (returns iterator), *???* (i.e. adjacent_find == end())

- mismatch (returns iterators), equal (i.e. mismatch == {end(), end()})

- find_if (returns iterator), none_of (i.e. find_if == end())

- find (returns iterator), contains (i.e. find != end())

- search (returns iterator), contains_subrange (i.e. search != end())

The proposal simply fills this gap. Or at least it *should* simply fill it.

@LoS: I'd be happy to coauthor if you like, and if you let me rewrite it in

Bikeshed format. ;)

(See my Bikeshed style in the latest proposals on this list:

https://quuxplusone.github.io/draft/ )

Right now the proposed specification is (1) too verbose, and (2) too

constrictive — it doesn't actually allow for the one use-case presented

above. (Instead it makes it quiet UB, which is awful. There's never a good

reason to introduce gratuitous UB into an STL algorithm.)

The right spec is no more or less than:

Effects: Equivalent to: `return std::adjacent_find(first, last, pred)

== last;`

Compare:

- https://eel.is/c++draft/alg.adjacent.find

- https://eel.is/c++draft/is.sorted#1

- https://eel.is/c++draft/alg.contains#1

my $.02,

Arthur

std-proposals_at_[hidden]> wrote:

> On Fri, Apr 14, 2023 at 11:02 AM LoS via Std-Proposals

> <std-proposals_at_[hidden]> wrote:

> >

> > As suggested in a reply to my previous proposal, I drafted a proposal to

> introduce the std::is_uniqued() function.

> >

> > Since it was developed from Arthur's idea, I would be very happy if you

> took part in the proposal.

> >

> >

> > I. Motivation

> >

> > The std::is_uniqued() function can be used to check if a range of

> elements has no consecutive equal elements.

> >

> > Even if there is already the std::adjacent_find() function, that can be

> used to get the same effect, the introduction of the function

> std::is_uniqued makes the check clearer, like std::contains() and

> std::is_sorted() do.

>

> Is this a thing people want to do? `std::contains` is a thing that

> people sometimes need to do as a distinct action from `std::find`.

> What code needs to detect if a range has "consecutive equal elements"

> *without* also wanting to know where that element is?

>

I don't know about "needs," but we do use this primitive in the *invariant

assertions* of flat_set and flat_map. So at least possibly "wants."

https://github.com/Quuxplusone/llvm-project/blob/trivially-relocatable-v60/libcxx/include/__flat_set/flat_set.h#L1055-L1059

The main motivation here IMHO is simple symmetry. Consider that we already

have

- is_sorted_until (returns iterator), is_sorted (i.e. is_sorted_until ==

end())

- is_heap_until (returns iterator), is_heap (i.e. is_heap_until == end())

- adjacent_find (returns iterator), *???* (i.e. adjacent_find == end())

- mismatch (returns iterators), equal (i.e. mismatch == {end(), end()})

- find_if (returns iterator), none_of (i.e. find_if == end())

- find (returns iterator), contains (i.e. find != end())

- search (returns iterator), contains_subrange (i.e. search != end())

The proposal simply fills this gap. Or at least it *should* simply fill it.

@LoS: I'd be happy to coauthor if you like, and if you let me rewrite it in

Bikeshed format. ;)

(See my Bikeshed style in the latest proposals on this list:

https://quuxplusone.github.io/draft/ )

Right now the proposed specification is (1) too verbose, and (2) too

constrictive — it doesn't actually allow for the one use-case presented

above. (Instead it makes it quiet UB, which is awful. There's never a good

reason to introduce gratuitous UB into an STL algorithm.)

The right spec is no more or less than:

Effects: Equivalent to: `return std::adjacent_find(first, last, pred)

== last;`

Compare:

- https://eel.is/c++draft/alg.adjacent.find

- https://eel.is/c++draft/is.sorted#1

- https://eel.is/c++draft/alg.contains#1

my $.02,

Arthur

Received on 2023-04-14 17:51:25