C++ Logo

std-proposals

Advanced search

Re: Relaxing *_with's common reference requirements to support move-only types

From: Justin Bassett <jbassett271_at_[hidden]>
Date: Tue, 13 Jul 2021 20:53:27 -0700
If anyone is following this, the proposal has seen some updates in the past
couple of days:

   - Briefly expands on the idea of removing the common reference
   requirement together to help clarify what would be needed to remove the
   requirement altogether.
   - In discussing how this is a breaking change, gives examples of code
   that is broken, and why breaking said code is worth it.
   - Improves the proposed fix to allow types with deleted rvalue
   constructors like some_ref(T&&) = delete; to work.

Thanks,
Justin

On Sat, Jul 10, 2021 at 3:19 PM Justin Bassett <jbassett271_at_[hidden]>
wrote:

> Hello,
>
> Please see the attached draft proposal. This expands on the earlier thread
> on relaxing the common reference requirements for equality_comparable_with.
> I updated the draft based on feedback on the other thread regarding adding
> comparisons to nullptr and nullopt.
>
> In short, this proposal relaxes the *comparison_relation*_with concepts
> by relaxing the common_reference_with requirement in a way to support
> move-only types, as previously the common_reference_with requirement
> requires copyability of the arguments if the common reference was not
> actually a reference. This proposal changes the convertible_to<const T&,
> CR> (where CR is the common reference) to convertible_to<T&&, const CR&>,
> which both allows avoiding the copy if CR is the same type as T and avoids
> the copy (calling CR(const T&)) of T if CR is not the same type as T.
>
> One concern I have is with respect to the semantic requirements in the
> proposed wording. It might be giving the impression that two values are
> only *comparison_relation*_with if they are non-const, but this is not
> so; they can be const, but the operator@ must yield the same result
> ignoring side effects as if the lvalues were non-const. I'm not sure if the
> proposed wording properly captures that.
>
> Thanks,
> Justin Bassett
>

Received on 2021-07-13 22:53:46