Re: [Boost-bugs] [Boost C++ Libraries] #11835: boost::has_trivial_copy is incorrect on Clang

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11835: boost::has_trivial_copy is incorrect on Clang
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-12-09 20:00:50

#11835: boost::has_trivial_copy is incorrect on Clang
  Reporter: | Owner: johnmaddock
  joseph.thomson@… | Status: new
      Type: Bugs | Component: type_traits
 Milestone: To Be | Severity: Problem
  Determined | Keywords: has_trivial_copy clang memcpy
   Version: Boost | is_trivially_copyable
  1.59.0 |
Resolution: |

Comment (by joseph.thomson@…):

 As far as I can see, the standard unambiguously states that deleted copy
 constructors (and other similar functions) are trivial. I quote from the
 C++14 draft:

> [class.copy]
> A copy/move constructor for class X is trivial if it is not '''user-
 provided''', its parameter-type-list is > equivalent to the parameter-
 type-list of an implicit declaration, and if
> - class X has no virtual functions and no virtual base classes, and
> - class X has no non-static data members of volatile-qualified type,
> - the constructor selected to copy/move each direct base class
 subobject is trivial, and
> - for each non-static data member of X that is of class type (or array
 thereof), the constructor > selected to copy/move that member is trivial;
> otherwise the copy/move constructor is non-trivial.

 The key term here is "user-provided". Are deleted functions user-provided?

> [dcl.fct.def.default]
> A function is user-provided if it is user-declared and '''not
 explicitly''' defaulted or '''deleted''' on its first declaration.

 There is no way around it: `T` has a trivial copy constructor.

 But how about `T` being trivially copyable?

> [class]
> A trivially copyable class is a class that
> - has no non-trivial copy constructors,
> - has no non-trivial move constructors,
> - has no non-trivial copy assignment operators,
> - has no non-trivial move assignment operators, and
> - has a trivial destructor.

 We have already established that the copy constructor is trivial. The
 other functions aren't even user-defined, so they must be trivial too. The
 unavoidable conclusion is that `T` is trivially copyable. For
 completeness, here is the definition of `std::is_trivially_copyable`:

> [meta.unary.prop]
> Template: `template <class T> struct is_trivially_copyable;`
> Condition: `T` is a '''trivially copyable''' type

 In my opinion, it does make sense, seeing as `is_trivially_copyable`
 simply states whether the object can be safely `memcpy`'d. Perhaps it's a
 badly named trait, but you can't deny what the standard says. An object
 doesn't need to have a copy constructor or assignment operator to be
 `memcpy`'d. Besides, what would the requirement be if they were needed?
 One or the other, or both? Seems better just to separate these concepts
 out into `std::is_trivially_copy_constructible` and
 `std::is_trivially_copy_assignable`, which is indeed what they did.

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:19 UTC