Re: [lmi] Detecting whether move semantics actually take place

[Vadim Zeitlin]

On Sun, 2 Oct 2022 23:25:37 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 7/28/22 14:08, Greg Chicares wrote:
GC> > On 7/23/22 15:41, Vadim Zeitlin wrote:
GC> >> On Thu, 21 Jul 2022 00:53:01 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> >> 
GC> >> GC> On 7/18/22 16:19, Vadim Zeitlin wrote:
GC> >> GC> > On Mon, 18 Jul 2022 15:48:14 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> 
GC> [I had wondered whether it would be fruitful to write assertions like 
this...]
GC> 
GC> >   static_assert( lmi::is_effectively_copyable <A>);
GC> >   static_assert( lmi::is_effectively_moveable <A>);

 To be honest, I still don't have a convincing answer to this question.

GC> With that in mind, I went back to older commits that had defined either
GC> all five SMFs or none of them, e.g.:
GC> 
GC> $ git --no-pager log --oneline --grep='Rule of Zero' 
GC> 6a59da54 When in doubt, prefer the Rule of Five to the Rule of Zero
GC> 702c4cdd Follow the Rule of Zero (initializing all data members in class)
GC> 7d05361b Follow the Rule of Zero, even expunging a virtual dtor
GC> 601db178 Follow the Rule of Zero
GC> 
GC> and added such assertions, "making the Rule of Zero safe": see
GC> new branch 'odd/concepts_smf'. I did that on a branch because I'm
GC> not sure whether it's worth doing or not, and because it raises
GC> some issues that I haven't grappled with yet. The case in favor of
GC> doing this is:
[...]

 I agree that this is more robust than relying on clang warnings, but the
question for me is whether it's worth writing all these extra checks. The
warning is nice because you don't have to do anything special to do in
order to get it, other than just defining the move SMFs as default. But, of
course, you could say that writing assertions in the code is better
precisely because they document the expectations more clearly, even if more
verbosely.

GC> This raises a broader question: using concepts, should we establish
GC> a taxonomy for lmi classes, and statically assert that each of
GC> these hundreds of classes fits its intended category? This goes far
GC> beyond movability: for example, is it useful in general to assert
GC> that a class is at least std::semiregular unless there's a good
GC> reason for it not to be?

 I don't think so, IMHO we're not going to gain enough from this. It could
be an interesting exercise, I guess, but it just doesn't seem to be worth
it from a practical viewpoint.

GC> That raises another question: are concepts really all that useful
GC> for classes, as opposed to the template parameters of class
GC> templates?

 Generally speaking, not very, but your example shows that they can still
be helpful in order to establish, and document, the requirements satisfied
by the class.

 Concepts are very new to me, so I don't have any experience to draw on and
I don't really know if it's worth starting to use them in this way. I'd at
least look at the implications for the compilation time because if adding
these checks makes the code twice slower to compile, it would be a strong
argument against doing it, IMO.

 Sorry for the lack of any real answer,
VZ

pgpvaJ3Mxcxkv.pgp
Description: PGP signature