Re: [lmi] depr.impldec

[Vadim Zeitlin]

On Thu, 28 Jul 2022 17:22:05 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> > GC> Unless we guarantee that it cannot happen, e.g., with "concept" 
assertions.
GC> > 
GC> >  True, but this would require using concepts in all places where the class
GC> > is used rather than defining the special member functions in a single
GC> > place, so it's not clear if it provides a gain from the brevity point of
GC> > view.
GC> 
GC> Really? Suppose I have:
GC> 
GC>   class X {...whatever...};
GC>   
static_assert(lmi_is_effectively_moveable_and_copyable_and_at_least_semiregular);
GC> 
GC> I believe that the static_assert() (provided that it doesn't fire) 
guarantees
GC> that X has the asserted properties everywhere and always, and that it's 
sufficient
GC> to write the assertion OAOO, in the header, probably right after X's 
definition.

 Yes, you're certainly right about this.

 I was thinking about writing concepts in the (template) functions that
really need them, i.e. taking "lmi::movable&& something" as a parameter
rather than "T&& something", but you don't want (and don't have, because
you're writing an application, with a closed set of type, not a library,
which necessarily must work with an open set of them) to do this. Sorry, I
got confused here.

GC> > GC> But we can write them all once...
GC> > GC> 
GC> > GC>   #include "crtp_base.hpp"
GC> > GC> 
GC> > GC> ...and only once:
GC> > GC> 
GC> > GC>   class A : private lmi::polymorphic_base<A> {};
GC> > GC>   static_assert( std::is_polymorphic_v           <A>);
GC> > GC>   static_assert( std::is_default_constructible_v <A>);
GC> > GC>   static_assert( std::is_destructible_v          <A>);
GC> > GC>   static_assert( std::is_copy_constructible_v    <A>);
GC> > GC>   static_assert( std::is_move_constructible_v    <A>);
GC> > GC>   static_assert( std::is_copy_assignable_v       <A>);
GC> > GC>   static_assert( std::is_move_assignable_v       <A>);
GC> > GC> 
GC> > GC> (and those assertions can be combined into one "concept").
GC> > 
GC> >  Just to be sure, did you really mean write all these asserts positively
GC> > like this or was it a typo?
GC> 
GC> That was cut and pasted from a (locally modified) copy of a unit test,
GC> which passes: none of those assertions fires. I think you could copy
GC> and paste it into 'crtp_base_test.cpp' and build it successfully
GC> (but I hope to push it soon enough).
GC> 
GC> > Because I'd expect polymorphic types not to
GC> > be copyable nor movable.
GC> 
GC> Class A above is both.

 You seem to be thinking that this is an advantage, but IMO it's a problem.
It should _not_ be neither copyable nor movable, i.e. lmi::polymorphic_base
should delete the corresponding special member functions. Copying an object
of polymorphic class is almost invariably a mistake (see: slicing).

 Sorry if I'm missing something obvious again here, but surely you want to
prevent people from copying base objects, don't you?

VZ

pgpn5I4XZepHv.pgp
Description: PGP signature