Date: Fri, 19 Jan 2024 22:38:58 -0600
Thank you for your reply and support for introducing a customization point
for container queries in C++. Here is a summary of the options you
proposed...
> 1. relying on the implementation to handle std::ranges::contains
> specially for standard library containers
This approach may offer simplicity, but it lacks explicitness. It doesn't
provide the clarity and uniformity that a dedicated function or member
would. Relying on implementation details could lead to inconsistencies
across different compilers and library implementations.
> 2. adding this new std::contains customization point
Adding *std::contains* as a customization point allows for a clear,
explicit, and standardized way to query containers. It works well with the
standard library's current design and is adaptable to different container
types, according to library implementers.
> 3. adding a contains() member function to all containers
This would provide a direct and intuitive way to query containers. But, it
requires modifying all existing container classes and may not be feasible
for non-standard or user-defined containers without imposing a new
requirement on their design.
> 4. simply burdening the user with making their own customization point
It offers flexibility (and I am most against), and it goes against the
principle of reducing boilerplate code and providing common functionality
in the standard library. It *could *lead to duplicate efforts and
inconsistent implementations in different codebases.
Also, I appreciate your opposition to the initial design and your
suggestion to split the functionality into two distinct functions:
std::contains_all and std::contains_any. Here are the revised signatures
for containers based on your feedback and going forward:
*std::contains_all* checks if all specified elements are present in the
container...
template <typename Container, typename... T>
bool contains_all(const Container& container, const T&... values);
*std::contains_any c*hecks if any of the specified elements are present in
the container...
template <typename Container, typename... T>
bool contains_any(const Container& container, const T&... values);
Robert
This communication contains confidential information and may be
privileged. If you are not the intended recipient or believe that you have
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. You should also not print,
copy, re-transmit, disseminate, or otherwise use the information unless
expressly indicated in this communication.
On Fri, Jan 19, 2024 at 3:45 PM Jan Schultke <janschultke_at_[hidden]>
wrote:
> I generally support the idea of *some* customization point, but there
> needs to be a critical examination of all available options:
> 1. relying on the implementation to handle std::ranges::contains
> specially for standard library containers
> 2. adding this new std::contains customization point
> 3. adding a contains() member function to all containers
> 4. simply burdening the user with making their own customization point
>
> It's not obvious whether your chosen direction is best.
>
> > bool containsOne = std::contains(numbers, {1, 4, 5}); // true
>
> I *strongly* oppose this design. If you want this, you should make two
> separate functions:
> - std::contains_all
> - std::contains_any
>
>
> Sincerely
> Jan
>
for container queries in C++. Here is a summary of the options you
proposed...
> 1. relying on the implementation to handle std::ranges::contains
> specially for standard library containers
This approach may offer simplicity, but it lacks explicitness. It doesn't
provide the clarity and uniformity that a dedicated function or member
would. Relying on implementation details could lead to inconsistencies
across different compilers and library implementations.
> 2. adding this new std::contains customization point
Adding *std::contains* as a customization point allows for a clear,
explicit, and standardized way to query containers. It works well with the
standard library's current design and is adaptable to different container
types, according to library implementers.
> 3. adding a contains() member function to all containers
This would provide a direct and intuitive way to query containers. But, it
requires modifying all existing container classes and may not be feasible
for non-standard or user-defined containers without imposing a new
requirement on their design.
> 4. simply burdening the user with making their own customization point
It offers flexibility (and I am most against), and it goes against the
principle of reducing boilerplate code and providing common functionality
in the standard library. It *could *lead to duplicate efforts and
inconsistent implementations in different codebases.
Also, I appreciate your opposition to the initial design and your
suggestion to split the functionality into two distinct functions:
std::contains_all and std::contains_any. Here are the revised signatures
for containers based on your feedback and going forward:
*std::contains_all* checks if all specified elements are present in the
container...
template <typename Container, typename... T>
bool contains_all(const Container& container, const T&... values);
*std::contains_any c*hecks if any of the specified elements are present in
the container...
template <typename Container, typename... T>
bool contains_any(const Container& container, const T&... values);
Robert
This communication contains confidential information and may be
privileged. If you are not the intended recipient or believe that you have
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. You should also not print,
copy, re-transmit, disseminate, or otherwise use the information unless
expressly indicated in this communication.
On Fri, Jan 19, 2024 at 3:45 PM Jan Schultke <janschultke_at_[hidden]>
wrote:
> I generally support the idea of *some* customization point, but there
> needs to be a critical examination of all available options:
> 1. relying on the implementation to handle std::ranges::contains
> specially for standard library containers
> 2. adding this new std::contains customization point
> 3. adding a contains() member function to all containers
> 4. simply burdening the user with making their own customization point
>
> It's not obvious whether your chosen direction is best.
>
> > bool containsOne = std::contains(numbers, {1, 4, 5}); // true
>
> I *strongly* oppose this design. If you want this, you should make two
> separate functions:
> - std::contains_all
> - std::contains_any
>
>
> Sincerely
> Jan
>
Received on 2024-01-20 04:39:43