You can be sure when the library author provides a strict mathematical proof that his algorithm works under the given requirements. For example, the Euclidean algorithm works for all Euclidean domains (and Euclidean domain is essentially a semantic concept).

For the library author, the iterative process does not end after a certain “number of iterations”; you have to iterate until you find a mathematical proof.

]]>The user needs to rely on the library author, who defined the concept, that he communicated all the semantic requirements.

This post is telling the story of the library author failing to do their part of the job. If the library author were aware of semantic requirements of the concept and communicated them clearly, then the user would have a clean situation: learn al declared semantic requirements, determine if my type is satisfying them, and sign off by specializing the “enable” trait.

Now, you could ask how the library author knows that all the semantic requirements have been identified and listed for their concept. The strict answer to this question is, you can never be sure. The practical answer is, designing a good interface (concept in this case) is an iterative process. You declare what you think is right, then you try to use it, see why it doesn’t work, and refine it. After a number of iterations you get enough confidence that you did it right.

]]>How does the user now what “all” semantic requirements are?

]]>Concept `Addable`

has in fact *many* semantic requirements. In the post I have mentioned one more: that operators + and += are consistently defined. But there are more. For instance, for the second overload, I require that relational operations and addition work in tandem:

a > 0 && b > 0 => a + b > a

If I added one variable per every single semantic requirement, users would have to take care of plenty of them. Instead I chose to mimick what OO-polymorphism does: there is one declaration of conformance which says, “I accept *all* semantic requirements”.

Thanks 🙂

]]>However, for exercise it is, let’s say okay… ]]>

I should clarify: It was a bug before GCC9 in some contexts, now it is fixed:

https://wandbox.org/permlink/i2Zf7xwlPHKwKu0f

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86678