Re: [boost] [variant2] Formal review

Subject: Re: [boost] [variant2] Formal review
From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2019-04-16 16:31:33

Le mardi 16 avril 2019 Ã  08:47 -0600, Steven Watanabe via Boost a
écrit :
> AMDG
> 
> On 4/16/19 5:18 AM, Andrzej Krzemienski via Boost wrote:
> > <snip>However, I propose
> > to depart from this model and adapt a more nuanced one. Let's
> > introduce a
> > new term: "effective invariant": this is a constraint on object's
> > state
> > much as "invariant". It determines what values an object can assume
> > in a
> > program where programmers adhere to the important principles that
> > are
> > necessary for programs to be correct. We can list some of them:
> > 
> 
> This is nonsense.  Either something is an invariant
> or it isn't.  If it isn't an invariant, then it's
> a precondition of every function that assumes that
> it is true.  Handling it in this manner isn't wrong,
> per se, but it is more complex and therefore more
> error prone.  You can't have your cake and eat it, too.
> Calling it an "effective invariant," just encourages
> treating it as if it were a real invariant.

I don’t see this as nonsense. Let’s divide functions in three
categories :

* the ones that have additional requirements over the invariants :
these preconditions are set / documented at the function signature
level
* the ones that expect the "effective invariant" to be true. This is
most functions, no definition/documentation of precondition should be
mandatory
* the ones that can really accept an object in any state. This is
special function, usually error handling ones. This is also defined /
documented.

I do think that it makes a lot of sense. I think reasoning that way is
an improvement over ending up with preconditions such as
is_not_valueless(v) everywhere in your code (or, worse, actually
handling such exceptional states in places it will never happen).
There’s a real symetry, and one way is actually closer to the
programmer’s intent, and less error prone.

Just to make an analogy, consider a raw C pointer. Your functions can
either allow it to be nullptr, or assume it is not (up to the caller to
honor the precondition). Whether you consider that the default is to
allow everything, and documenting if you do not, or that the default is
to forbid nullptr, unless explicitely allowed, is more a convention
than anything else. You’ll find both ways in documentations.

Regards,

Julien