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,
 and
 >  - 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: <https://svn.boost.org/trac/boost/ticket/11835#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.