Re: [boost] [contract] move operations and class invariants

Subject: Re: [boost] [contract] move operations and class invariants
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-11-30 23:43:45

On 30/11/2017 20:48, Andrzej Krzemienski wrote:
>> In general you should expect to be able to call any method which is valid
>> on a default-constructed object, *especially* assignment operators (as it's
>> relatively common to reassign a moved-from object).  (You cannot, however,
>> actually assume that it will return the same answers as a
>> default-constructed object would.)
> 
> Agreed (assuming you meant "on a moved-from-object" rather than "on a
> default-constructed object"), but while such an object is "valid", this
> information is of little use in some cases. And I think it is such cases
> that are relevant for creating class invariants.

Not quite.  I meant "you should be able to call any method on a 
moved-from object that is valid for a default-constructed object", ie. 
those without strict preconditions, ie. the class invariant should still 
hold and the object should still be in a valid state -- you just can't 
assume any particular state (neither empty nor full nor somewhere in 
between).

As such it is usually only reasonable to perform those operations which 
cause a well-defined postcondition state regardless of the initial state 
-- ie. assignment, destruction, or explicit clearing or resetting or 
things of that nature.

But it would also be legal to perform other operations and then 
interrogate the object about its resulting state -- but that's rarely 
useful in practice as it's a possible source of nondeterminism in 
different environments, and usually we want our software to be more 
predictable. :)

> Let me give you some context. I would like to create a RAII-like class
> representing a session with an open file. When I disable all moves and
> copies and the default constructor (so that it is a guard-like object) I
> can provide a very useful guarantee: When you have an object of type `File`
> within its lifetime, it means the file is open and you can write to it, or
> read from it.
> 
> This means calling `file.write()` and `file.read()` is *always* valid and
> always performs the desired IO operation. When it comes to expressing
> invariant, I can say:
> 
> ```
> bool invariant() const { this->_file_handle != -1; }
> ```
> 
> (assuming that -1 represents "not-a-handle")
> 
> But my type is not moveable. So I add move operations (and not necessarily
> the default constructor), but now I have this moved-from state, so my
> guarantee ("When you have an object of type `File` within its lifetime, it
> means the file is open and you can write to it, or read from it") is no
> longer there. You may have an object to which it is invalid to write. Of
> course, the moved-from-object is still "valid", but now "valid" only means
> "you can call function `is_valid()` and then decide" (and of course you can
> destroy, assign, but that's not the point).

As soon as you add those move operations which can put the class into a 
state where the invariant no longer holds, then it's not an invariant 
any more.  At best it becomes preconditions for most of the methods. 
This should be self-evident.

(Move-assignment isn't too bad, as that can be implemented as a pure 
swap, which will maintain invariants.  But move-construction is an 
invariant-killer, because it's effectively a swap with nothingness.)

Any time that you have a class that wants to provide a "no empty 
guarantee", and you want to add a move operation to it, you have a 
problem.  I recommend not trying to mix these concepts -- while not 
completely incompatible, they don't play nicely together.

(This also applies to default construction -- if you find yourself 
wanting to make something non-default-constructible because that would 
make it somehow invalid, then it probably shouldn't be moveable.)

If you want to make a file handle that you can move, then you should 
sacrifice the no-empty guarantee and allow it to default-construct to 
"no file open", and return to that state when moved-from.  And yes, then 
you need to check *at certain boundaries* and after certain operations 
that you've been given a non-empty handle.  Emptiness is not an 
unexpected state for a file handle, so this should surprise nobody.

(And you then have to decide an appropriate balance between setting 
preconditions but merely asserting them in debug builds, or verifying 
them explicitly in all builds and returning errors or throwing 
exceptions.  But that's true for anything.)

Another option if you really want to retain both no-empty and 
moveability is to wrap it in a unique_ptr.  Now you're moving the 
pointer to the object, not the object itself, which remains immobile. 
It still means you have to check if someone's handed you an empty 
pointer -- but you can be more explicit at the boundaries, with methods 
taking a unique_ptr<File> (&& or const&) if they will be checking if 
it's empty or taking a File (& or const&) if they assume they've been 
given a non-empty one.

Granted that it is *possible* to implement move operations on a no-empty 
class, but AFAIK this invariably leads to producing a zombie object 
where any attempt to use it other than for assignment or destruction 
would produce UB due to violated preconditions (and consequently also 
weakening the class invariant to become method preconditions).  This 
seems like a really bad idea to me.