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