[Development] What's the status of a moved-from object?

[Allan Sandfeld Jensen]

On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> On 2019-05-20 17:16, Thiago Macieira wrote:
> > On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
> >> Or maybe we don't disagree at all and Thiago would accept allocating
> >> memory (or, by extension, anything that's noexcept(false)) as a very
> >> good reason to have a nullptr d?
> > 
> > I hadn't thought of noexcept, but let's be clear: yes, move
> > constructors must
> > be noexcept. That might be the good reason why it can't reset to a
> > valid
> > state.
> 
> What a feat it would be if Qt celebrated the 10th anniversary of the
> publication of Elements of Programming with embracing the
> partially-formed state :)
> 
> So, we seem to agree that moved-from objects may have d == nullptr. In
> the following, let this be our premiss.
> 
> Where we still, maybe, disagree, is whether d == nullptr is a valid
> state. The difference is whether member functions other then destruction
> and assignment check for a nullptr d. I'd propose that on classes under
> the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the
> best balance between safety and speed.

I agree. I would consider anything other than deleting or reassigning  a moved 
object undefined behavior, so asserting on it seems like a good help to users 
of our APIs.

I would add though that if the class has an isValid() method that method 
should be callable, and must returns false.  Not sure about a possible 
isNull() method :/ That whole subject btw, probably needs some cleanup. 
Wrappers with undefined, invalid and null values have been getting a bit mixed 
up in Qt APIs, and that gets confusing when some the values we wrap are stuff 
like JSON and SQL that has defined null values.

Best regards
'Allan