Title
Simplify constraints for semiregular-box
Status
c++23
Section
[range.move.wrap]
Submitter
Casey Carter

Created on 2020-08-19.00:00:00 last changed 5 months ago

Messages

Date: 2020-11-09.21:40:50

Proposed resolution:

This wording is relative to N4861.

  1. Modify [range.semi.wrap] as indicated:

    -1- Many types in this subclause are specified in terms of an exposition-only class template semiregular-box. semiregular-box<T> behaves exactly like optional<T> with the following differences:

    1. (1.1) — […]

    2. (1.2) — […]

    3. (1.3) — If assignable_from<T&, const T&>copyable<T> is not modeled, the copy assignment operator is equivalent to:

      semiregular-box& operator=(const semiregular-box& that)
        noexcept(is_nothrow_copy_constructible_v<T>)
      {
        if (that) emplace(*that);
        else reset();
        return *this;
      }
      
    4. (1.4) — If assignable_from<T&, T>movable<T> is not modeled, the move assignment operator is equivalent to:

      semiregular-box& operator=(semiregular-box&& that)
        noexcept(is_nothrow_move_constructible_v<T>)
      {
        if (that) emplace(std::move(*that));
        else reset();
        return *this;
      }
      
Date: 2020-11-09.00:00:00

[ 2020-11-09 Approved In November virtual meeting. Status changed: Tentatively Ready → WP. ]

Date: 2020-09-15.00:00:00

[ 2020-09-03; Reflector prioritization ]

Set priority to 0 and status to Tentatively Ready after six votes in favour during reflector discussions.

Date: 2020-08-19.00:00:00

The exposition-only semiregular-box class template specified in [range.semi.wrap] implements a default constructor, copy assignment operator, and move assignment operator atop the facilities provided by std::optional when the wrapped type is not default constructible, copy assignable, or move assignable (respectively). The constraints on the copy and move assignment operator implementations go out of their way to be unnecessarily minimal. The meaning of the constraint on the copy assignment operator — !assignable<T, const T&> — has even changed since this wording was written as a result of LWG reformulating the implicit expression variations wording in [concepts.equality].

It would be much simpler for implementors and users if we recall that minimality is not the primary goal of constraints and instead constrain these assignment operators more simply with !movable<T> and !copyable<T>.

History
Date User Action Args
2023-11-22 15:47:43adminsetstatus: wp -> c++23
2020-11-09 21:40:50adminsetmessages: + msg11590
2020-11-09 21:40:50adminsetstatus: ready -> wp
2020-09-03 19:09:35adminsetmessages: + msg11472
2020-09-03 19:09:35adminsetstatus: new -> ready
2020-08-23 16:34:59adminsetmessages: + msg11460
2020-08-19 00:00:00admincreate