Date: Mon, 27 Feb 2023 23:08:33 -0500
On Mon, Feb 27, 2023 at 10:37 PM Mingxin Wang via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> When instantiating `std::map` or `std::unordered_map`, the value type could be non-copyable (but movable). However, both class templates have copy ctors and assignments. I do not see any wording suggesting they shall be deleted like `std::optional` does ([optional.ctor] Remarks: This constructor is defined as deleted unless is_copy_constructible_v<T> is true. If is_trivially_copy_constructible_v<T> is true, this constructor is trivial.) Shall we refine the wording here?
The table in [container.reqmts] outlines the requirements for all
containers. Under copy construction and assignment expressions, there
is a precondition that prevents those functions from working if `T` is
not CopyInsertable or Assignable.
I don't think the term "precondition" is appropriate here, though, as
precondition violations are supposed to be runtime UB, while these
checks are based on compile-time properties. This is probably meant to
be a "constraint", but this section long predates the new
constraint/precondition definitions.
Cleanup for the wording might be extensive enough to need a paper. But
the wording as it stands makes it clear what the intent is, so there's
no need for a proposal for a change.
<std-proposals_at_[hidden]> wrote:
>
> When instantiating `std::map` or `std::unordered_map`, the value type could be non-copyable (but movable). However, both class templates have copy ctors and assignments. I do not see any wording suggesting they shall be deleted like `std::optional` does ([optional.ctor] Remarks: This constructor is defined as deleted unless is_copy_constructible_v<T> is true. If is_trivially_copy_constructible_v<T> is true, this constructor is trivial.) Shall we refine the wording here?
The table in [container.reqmts] outlines the requirements for all
containers. Under copy construction and assignment expressions, there
is a precondition that prevents those functions from working if `T` is
not CopyInsertable or Assignable.
I don't think the term "precondition" is appropriate here, though, as
precondition violations are supposed to be runtime UB, while these
checks are based on compile-time properties. This is probably meant to
be a "constraint", but this section long predates the new
constraint/precondition definitions.
Cleanup for the wording might be extensive enough to need a paper. But
the wording as it stands makes it clear what the intent is, so there's
no need for a proposal for a change.
Received on 2023-02-28 04:09:23