22 March 2019 – By V.Oddou

Today it’s going to be a technical, computer science engineering article about C++ practices:

The Principle of Maximum Opportunity (in C++)
let’s call it MOP !

Preface

MOP is when you mind your programming style, so that your code becomes emergently interlockable.

When we code, we have a voice in the back of our head that drives us to make choices according to some gut-felt metrics. It is a permanently on-going process that sets in motion all our history of experience, digested in the form of acquired knowledge. Sometimes unconscious when it’s pure personal experience. Sometimes conscious, when we can even put a name on these metrics. Some of these can be:

• cyclomatic complexity (too much branching)
  • by extension, the zen of python: Special cases aren’t special enough to break the rules.
• readability
• bad names
  • heavy cognitive payload (SubSystemKernelTimestampCanonicalizer)
  • too generic (data, manager…)
  • devoid of entropy (a, b…)
  • unexplained magic constants
• lenght of a line
• number of lines of code
• depth of indents
• number of responsibilities
• whatnot…

A metric bubbles up at the conscious level when a “language” is defined to reason about it.
That happens when you learn about it from scholar sources for instance.
Nicolas Boileau said “ce qui se concoit bien s’ennonce clairement” (What you understand well, you enunciate clearly).
It’s not important to not have words to put on your practices when you work alone. But in teams as soon as code reviews come up, you need to communicate your intents and that only can find its way through the keyboard if you have letters to apply to them. So let’s all read more articles like this one !

That was for metrics, but there are also principles. There are a number of enumerated “good practices” principles already. e.g: SOLID, DRY, YAGNI, KISS, POLA, code cohesion, decoupling…
They are taken for granted throughout this article.

There are design patterns (Which are frankly less important because they are naturally re-invented as their need arise). Let’s cite some for illustration: Factory, Command, Policy/Strategy, Consumer/Producer, Decorator, Adapter, Iterator, MVC…

Finally there are idioms. These are language specific, by definition of the term. NVI, CRTP, RAII, SFINAE, ADL customization points, copy-and-swap, erase-remove, pimpl, safe-bool-idiom, rule of zero…

Let’s go Lego™

Now, on to the meat for today: practices of the Principle of Maximum Opportunity (MOP).

Let’s start by introducing this principle of classical mechanics I like: isostatism versus hyperstatism.
In the English-speaking world, most often known as statically determinate versus statically indeterminate. I’ll let you google it for explanation, or duckduckgo it for anonymous explanation. But in simple words: isostatism is when you won’t have an issue assembling parts because they have leeway for manufacture imprecision.
Example: an isostatic bookshelf has 2 screw holes to prepare on the wall, and wherever they are, it will just attach with no hurdle.
Hyperstatism is when you start to have a row of 3 or more screw holes to prepare. If you miss-align your screw hole by two millimeters, then your bookshelf just won’t hook.
In one case there is just enough constraints to get the job done, in the other case, there are too many constraints. The usual tradeoff is solidity, but it’s also possible to uselessly lose degrees of freedom. In computer science, that principle best matches DRY.

auto

For those familiar with C# and resharper, this one is a no brainer since you get constant rewrites as you type code into var instead whatever type you input. But for C++ people, decades of explicit typing practices are making it a hard-to-sell. Many coding rules advocates keeping explicit typing unless the type would otherwise appear two times on the same statement.

auto client = LookupClient("john");

In this case I would argue that nobody should care what type is the client variable, as long as it is readable that it is a client. It could be a Client type, but it could be a reference wrapper to a client object for all we know; and it should not matter. In the above case, the type appears nowhere so many C++ programmers are ill-at-ease with using auto​ since the type doesn’t appear. In my experience when I’m really curious I just let the intellisense’s tooltip tell me the type, but there is always someone to complain that not everybody’s editor is visual studio.

Client client = LookupClient("john");

In that case, older C++ geezers can rest at peace since the type is stated, but what entropy have you gained ? And what is the degree of statism in that expression ? It’s 2 degrees hyperstatic, because the word client appears 3 times. That is two times too many.

auto john = LookupClient("john");

This is now isostatic since client appears once. It means this expression is now free to evolve as maintenance goes on in the program’s life, if the type changes to a reference wrapper, or if the concept of client itself changes to customer ? The function can be renamed and this expression will still be OK because the variable doesn’t re-expresses the type in the name of the symbol.

To me, auto has a bit of an unfortunate name for hysterical raisins. But it should be as natural as var in C#. But also kind-introducing declarativevar and let in Nim, Swift and typescript, let and mut in Rust. Mathematics also uses this kind-introducing notation, and has inspired numerous functional languages for variable and function declaration. There is also a visible industry-wide convergence in languages towards the typescript syntax. The Curry-Howard correspondence hints in that direction too. I think it is a force to be reckoned with. auto is such a form, and it allows to reach isostatism. Which means →it’s MOP ! You will also have noticed how DRY it is as well.

Implied interface

That is a notion used in the stdlib through names like empty, begin, end, size… and in metaprogramming with the ::value and ::type names.
See a nice article about implied interface described as a pattern: http://www.shindich.com/sources/patterns/implied.html
extract:

«Establish an interface abstraction implicitly by using functional polymorphism in the cases where the use of explicit interface constructs is either unavailable or would cause excessive refactoring of object-oriented code.»

Another one I like, making the very-needed parallels with duck-typing: https://devopedia.org/duck-typing

I’ll criticize two points of interest, quoting:

«Duck Typing is a way of programming in which an object passed into a function or method supports all method signatures and attributes expected of that object at run time. The object’s type itself is not important. Rather, the object should support all methods/attributes called on it.»

Here: the “run time” part is not necessary, I think it’s only a historical consideration to circle the concept to where and how it really happened in practice. But I think it’s fine to enlarge the definition to build-time as well. That’s where the second quote comes in:

Python doesn’t have explicit interfaces: interfaces are implied. For Python, this is not different from duck typing. However, implied interfaces are supported by C++ (for example) in its STL library. Given that C++ does compile-time checks, we can’t say in general that implied interfaces is the same as duck typing. Note that when interfaces are implied, there’s no formal interface definition, and at best, it may a be shared documentation.

While the last bit is sort of true, since the advent of boost.traits combined with BOOST_STATIC_ASSERT the formality could be raised one notch. And in C++20, concepts are allowing full formalization of implied interfaces. If you take a look at the following doc page, you’ll see what I’m talking about:
https://en.cppreference.com/w/cpp/iterator#C.2B.2B20_iterator_concepts

extract: Readable:

specifies that a type is readable by applying operator *

The presence of operator * is the implied interface, but now it’s formalized. Thanks to that concept of implied interface, we start to see that it’s possible to decouple the requirements, from the type. Without that feature, we had to rely on Interface Segregation Principle. Why ? Because it’s an overcoupling problem to pass objects which have too much responsibilities/data when you only need a sub-set of them. If you free yourself from the type and rather specify the input constraints, in the form of a formal implied interface rather than a specific type, ISP is much less necessary, and you still get build time checks; best of all worlds. Let’s look at an example:

struct Client
{
    string address;
    string name;
    Date   birth;
};

bool CanViewPorn(Client const& c)
{
    return (now() - c.birth).asyears() >= 18;
}

There is an issue with that code. Its hyperstatic degree 1 because of the over-requirement on the Client type. What if at some other place of your code, you now have:

struct Person
{
    Stuff thing;
    string name;
    Date   birth;
    int friends;
};

You could have had the opportunity of gaining Person to be a type passable to CanViewPorn, had you not over-constrained with the Client type. In this situation java purists will shout «use ISP naW!» and you’ll find yourself in this situation:

struct IBirthed
{
    virtual Date GetBirth() const = 0;
};

struct Client : IBirthed
{
    string address;
    string name;
    Date   birth;
    Date GetBirth() const override;
};

struct Person : IBirthed
{
    Stuff  thing;
    string name;
    Date   birth;
    Date   GetBirth() const override;
    int    friends;
};

bool CanViewPorn(IBirthed const& b)
{
    return (now() - b.GetBirth()).asyears() >= 18;
}

Brrr, this is dreadful. ISP in action. What a pile of smelly java crap, yes ! C++ doesn’t need this. In C++ we can «want speed ? pass by value» all over. Having interfaces forces us into the references and pointers world. Not to mention this catastrophic verbosity. And obviously, the potential runtime cost of the virtual dispatch, here utterly useless. That’s how real men do shit:

struct Client
{
    string address;
    string name;
    Date   birth;
};

struct Person
{
    Stuff  thing;
    string name;
    Date   birth;
    int    friends;
};

template<typename Birthed>
bool CanViewPorn(Birthed b)
{
    return (now() - b.birth).asyears() >= 18;
}

There ! →implied interface in all its splendor. I’d argue that it’s even less coupled in that form than the explicit interface example above. You have opportunities to pass types with a «birth» field even if the original programmer never heard of the IBirth interface. At this point maybe you’re thinking of the python has_attr function. Because maybe you’re thinking that this template accepts any type, but it will fail to build were one to pass something that is not intended to be accepted. Then you’re thinking about using an existential.

template<typename Birthed>
requires( std::is_same_v<decltype(Birthed::birth),Date> )
bool CanViewPorn(Birthed b)
{...

That, is how real men do shit… next year. But well, joke aside, this is an existential.

A requires clause will change the template Birthed from a universal type to an existential type.

Uniformity of naming

As previously mentioned, begin(..) and end(..) are an example of names that are uniformly observed, so that types «that can bind to these functions by ADL, or called through method call», will be drop-in compatible. This is a practice observed when working with custom containers, the usual API of the closest equivalent container in stdlib is usually adopted in order to be close to drop-in replaceable. This is all the more true in C++11 now that we have ranged based for, that require begin/end to be callable. This does not extend only to stdlib related works, but also in any place in your own code that is designed to rely on implied interfaces in generic code.

Arities

When working with overloaded functions, they can be called in generic contexts only as long as the call site has a uniform syntax. That means, the same number of arguments (arity). If some functions have arity 1, and some 2, it just is not usable in generic contexts because now you have to take branches depending on the case. Overload sets are useful in that they decouple function resolution from the algorithm. The responsibility is in the compiler, to do type matching. Like auto, that precept respects isostatism.
Example:

void Div(float a, float b, float& res);
void Div(double a, double b, double defaultforzero, double& res);

template< typename Arithmetic >
void GodKnows(Arithmetic a, Arithmetic b)
{
    // stuff stuff stuff ...
    Arithmetic c;
    Div(a, b, c);
}

Function overloads can act as nice generic-exit points. If you visualize the template path like such:

That’s code call flow, on the left it starts from concrete implementations, then calls from heterogeneous types can flow through a factorized template function with generic code, but the exit nodes must flow back to concrete implementations per type supported. If you have an overload set, the template call will dispatch to the best overload. But that can only happen if your arity is consistent.
In this case Div for double will cause a problem. We might need to resort to if constexpr(std::is_same_v) to call the function with arity 4.

Consider even higher MOP: your calling code may be working with a build-time higher order function object list. Instead of calling ​Div(a, b, res); It could be:

constexpr int index = mpl::find<indices_tl, ThisOpT>::value;
constexpr auto myfuncPtr = mpl::at< functor_typelist_t, index >::value;
myfuncPtr(a, b, res);

Because all arity 2 math operations can use this code path. Be it Add, Sub, Mul or Div. Therefore, the high need of uniformity in your personal convention about arities of overload sets AND other closely related families of functions. If you fail to your conventions, you’ll force your higher order client code to branch uselessly.

Duck-typing

This is the hottest concept of this whole article, maximum opportunity is the big brother of duck-typing, in the sense that it is mostly similarly defined.
All the “guidelines” referred to hereunder are flavors of duck-typing philosophically.
I find it unfortunate that some articles about duck-typing define it as a feature of dynamic languages; and static languages should instead speak of «structural typing».

In python culture, is considered pythonic, code that assumes as less as possible about the types.
From this guide: https://docs.python-guide.org/writing/style/
bad: if attr == True: Good: if attr:
What’s the difference ? One works with only booleans, the other is canonical. You can duck-type any type that has a defined bool conversion.
In C++ that’s a lot of things. Smart pointers respecting the safe bool idiom would have this expression work, but not the first one, they would need a special == operator.
Conclusion, the second version increases the usage opportunities, that’s MOP !

ADL

In some cases, you refer to a very unique symbol by name, you know you want this one and no other. Example ::GetWindowHandle().
But, sometimes, you refer to something more vague. like sort, or swap, or size, or begin, or end…
For these cases, don’t use qualified names when you can open your chances to select a wider range of more efficient specializations in the whole scope of the program, via unqualified names and ADL.
This is a duck-typing-like principle but applied to overload resolution. It works only if you respect the implied interface principle. The committee is calling them, customization points.
example:

using std::swap; // activate the fallback
b = swap(a); // ADL lookup, now boost::swap will be considered
//or
using std::hash_value;
return hash_value(arg);  // mylib::hash_value has a better specialization ?

(Note that this does not apply to std::move, unless you are trying to emulate move in C++03)
This practice became a pattern around the time when boost realized it was possible to accelerate swap of containers, and provided specializations, in their namespace. Customization points are MOP !
For more about it, and an infinitely better explanation by master Niebler, I highly recommend: http://ericniebler.com/2014/10/21/customization-point-design-in-c11-and-beyond/
Along with why it’s non-ideal, and he also goes and proposes a fix (for the standard committee to consider), a great man.

Minimal type requirements

from the shindich article above, quote:

«libraries of generic algorithms impose minimal requirements on their subjects»

«type requirements» is a notion well known to STL designers (and hopefully clients).
It spoke of concepts, before the era of concepts. Requirements such as “must be default constructible” are listed for operations or containers which are template (and therefore take universal types). So until concepts, it was necessary to document these requirements on the side of the code alone.
It is naturally good practice to reduce requirements on types to the absolute minimum when you design generic code.
Reversely, type requirements are thus a notion of generic code; meaning templates come into play. But with C++20 templates are creeping innocently into all sorts of places thanks to the auto keyword. It has been yet again extended, do you remember the generic lambda of C++14 ? Now you’ll have generic functions too. So you start to see how easy templated code is going to popup all around, without the template keyword even to be seen. This is called abbreviated function templates. (However I’m not sure whether it will be accepted.)

Template (universal types)

A template brings maximum duck-typeability, because templates are completely type enabled (that’s the opposite of type erased). In type theory that means a template type T is a universal type. So let’s call these templates, universal templates. Or unbounded templates. This is extremely powerful because it’s barely syntax checked, this is called two phase lookup, and the first phase only looks-up non-dependent symbols.
Example:

template< typename T > void func()
{
   auto stuff = T::s_stuff; // valid because anything goes. just have to instantiate with T that has s_stuff
}

concepts (existential)

Concepts are the C++20 materialization of existential types. They are a balanced middle ground between java (type erasure) and unbounded templates.
This advent is an important turning point of this decade, major languages are showing a tendency to converge in feature set.
Nim has them, D has them, Go has them, C# has where clause, Haskell of course… Languages also converge in “functional”-ization.
With lambdas and algorithms, LINQ being a nice example. Pythonic constructs.
Which naturally brings us to… ranges 🙂

ranges (Eric Niebler)

link: http://ericniebler.com/2018/12/05/standard-ranges/

Ranges are a perfect example of the minimum type requirements principle. Let me do an introduction of ranges from my personal perspective:

#include <vector>
using namespace std;

int main()
{
    // say you have a concrete list of stuff
    int vals[] = {3, 80, 10, 5, 2};
    // now you want to refactor some action on it in a function
    sort(vals);  // c.f. under
}

// how is it going to look like ?
void sort(int vals[])
{
    // .. ah. how do I know the end ?
}

// change of plan !
void sort(int vals[], size_t len)
{
    // painful API...
}

// hmmm... ?
template< size_t N >
void sort(int (&vals)[N])
{
    // nice !
}
// all happy. but next day.. a new client appears

int main()
{
    .....
    std::vector<int> vals2 = {5,6,7};
    // ouch...
    sort(vals2); // wont do
}

// an overload for this sort of collection ?
void sort(std::vector<int>& vals)
{}

// back to the MOP principles I listed above:
// this is hyperstatic level 1:
// the type is not int[N] or vector.
// it is "collection of ints"

// this is why the stdlib does it this way:
void sort(iterator begin, iterator end)
{}

// unfortunately, the iterator type is not known upfront. so it's a template
template<typename iterator>
void sort(iterator begin, iterator end)
{}

// and there you have it. that's conceptually a range.
// this has been the solution for 22 years.
// but there are problems which led to the invention of real ranges.
// I'll let you explore Niebler's site or rangev3's github.
// I'll just say the new form is this:
template <std::InputRange R>
void sort(R&& r)
{}

A range can be viewed as the new form of 2 iterators. It solves everything and is magical and unicorns actually are painting rainbows over there. It brings the functional power of C#’s lazy LINQ expressions to C++. Ever worked with jinja2 filters (pipe operator) ? ranges has them. boost offered similar kewl stuff such as iterator adaptors back in the days, which is great when you have an algorithm that works on simple collections, but you have a map and you’d like to run that algorithm on the keys. If you don’t think about those kewl libraries, you have to incur the runtime costs of creating intermediate copies of your transformed collections.
Next time, think ranges, this is MOP !

universal reference

Or whatever new fad name came up for them, what was it again ? forwarding references ? Anyway, this stuff is maxi MOP, because it allows to feed-in anything from the client point of view, and you don’t have to duplicate code for const and non const stuff. For a better feel of how MOP this is, I’ll refer you to this standard proposal:  Range-Based For-Loops: The Next Generation, by Stefan Lavavej:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm
Quote:

This is a proposal to add the syntax “for (elem : range)”. In addition to
being easier for novices to learn and being clearer for everyone to read,
this will encourage correctness and efficiency.

Quote 2:

"for (auto elem : range)" is very tempting and very bad. It produces
"auto elem = *__begin;", which copies each element, which is bad because:
* It might not compile – for example, unique_ptr elements aren’t copyable.
This is problematic […] for users writing generic code that’ll happily
compile until someone instantiates it for movable-only elements.
* It might misbehave at runtime […]

for (auto& elem : range) is much better, although it’s not quite perfect.
It works with const/modifiable elements, and allows them to be observed/mutated
in-place. However, it won’t compile for proxy objects

[…] and manually specifying element types is equally bad or even worse:
[…] * "for (const Elem& elem : range)" is pernicious if the Elem type is incorrectly specified. If the range is map, then "for (const pair& elem : range)" will convert-copy each element (triggering the previously-described correctness/efficiency problems) because the map’s elements are actually pair

I’ll let you read the actual document for the redacted parts, I hope you are now fully convinced that auto is great, and that auto&& is maxi great. It deserves the ultimate MOP trophy. Because of course, while this paper is about loops (did you see what I did here?), it applies for all type deduction context.

const

I have a problem with this one. It feels to me that constness goes against DRY far more often than I can care. The more senior I become the more I tend to drop from the const fad train. It’s funny how const actually is anti-opportunity. When you think of duck-typing being an opportunity enabler, const is more of a disabler. It separates accessibility of symbols into two worlds, the world of consts and the world of mutables.  If you divide, you don’t unify →less MOP.
Maybe Rust handles that better with let and mut?

interface segregation

Use function parameter types that pin point the minimum needed. That maximizes the opportunities in the future for reuse. You know about that now from the Client/Person example from above. Let’s have a second one:

void func(iterator i) { code that assumes i is non end(), or don't care about next()/++i }
// better:
void func(container::value_type& i) { /* " */ }

It’s more related to dependency than segregation, but it’s by segregating that we can decouple. Here iterator and value_type have been segregated, therefore we can pass the abstraction that is a better fit for our requirements in the body of the function. This frees the dependency to a container. We can now use the function on free elements (not contained). Also we can’t pass an invalid iterator anymore, so the invariants are unbreakable.

Maximum genericity

Example: you make a compiler ? arrange your data model so that a class is a class, a struct is a class, a union is a class, an interface is a class, a namespace is a class…
If you can store everything in the same bag, already written algorithms downstream will emergently work, or only require minimum maintenance.

Though classic OOP requires interfaces to express genericity, it is in contradiction with “minimum type requirements”.
Therefore, I’m generally moving away from inheritance, and using techniques above instead. Not even mentioning the problem of risk of type slicing when working with value types. Which you should always prefer to avoid rampant fragmentation and cache misses. optional can help to avoid pointers too.

variant comes in handy for the considerations of the last paragraph. If you don’t have inheritance, that doesn’t absolve you from having to work with heterogeneous types sometimes. A trick that can be pulled out thanks to variant. You can now store adjacently in memory, heterogeneous objects, as long as they are not unreasonably disparate in sizes.
Activating genericity on variants will force you into the template game. Generic visit ? You’ll need a C++14 generic lambda, or make a visitor with templated operator().
And now, the implied interface principle comes back with a vengeance, because you see how important it’s going to be to have duck-typeable types in your variant.
Otherwise you’ll be doomed to implement an operator() per type, or switch on index (or holds_alternative), or at worst if constexpr (std::is_same<...) when it’s still possible to share some template code for some of the types. Or maybe go through an «extract method» refactoring, and create an overload set of functions that will canonicalize access ? example:

def type A with implied interface A
def type B with implied interface A
def type O as an outsider
using V = variant<A, B, O>;

// requires implied interface A
template< typename T >
void extracted(T t) { do stuff A style; }

void extracted(O o) { outsider things; }

V v = init;
std::visit( [](auto t) { ... preexec; extracted(t); postexec...; }, v);
// the extracted call will duck-type to the best overload at template instantiation. (the template is the lambda)

That’s the same broom graph from earlier (X with a – in the middle), on the left, the init line, is concrete. Then we converge to generic in the middle (the visit), then re-fan-out on the right to hit the concrete leaves (extracted). And again, another echo from before, this is the “respect your arity” principle. Now one generic call to extracted can fan-out to the proper overload.

Real life example: In the making of a compiler, I had to work on a function overriding semantic check. In the implementation of the validation system, I needed to verify that the declared function is hiding a name in the base. When bases can only be interfaces you know that symbols contained in a base are always functions.
So it’s tempting at first to write a query function named :
IsFunctionHiding(identifier currentFunc, identifier baseInterface). That’s a missed opportunity. Because the implementation of that query will have nothing particular to functions. So the signature should be changed to:
IsSymbolHiding(identifier overridingCandidate, identifier base). Now, for no cost, you have opened that query for reuse by, say, properties, when they get in the language. This is not YAGNI, it’s MOP !

Another example about variant use. In the codebase I’m working on we have a type using ConstNumericVal = variant; that allows to keep the information about the type while being able to store in a unified way (canonical) a parsed value of the activated type. Not having that facility would require boxing, and creating a polymorphic class hierarchy a la java. Which means pointers, and lots of boilerplate lines that never translate to any machine OPCode.

`Get` and `Has`

This pattern happens often. I noted that to avoid repeating yourself, Has ends up usually implemented as return Get() != end();
That’s a problem if you usually do in client side: if (Has()) auto elem = Get(); because now the query runs twice.
Today I prefer to get rid of Has entirely, and return an optional instead. This way you get the 2 functionalities in one function.
Let’s take an example in the stdlib: map‘s find() method. They applied the same principle, there is no equivalent to C# HasKey(). You find and check against end() yourself.
However that is imperfect, because of the now introduced dependency on the underlying collection. It was assumed that «since you could call find() on your collection, thus you have said collection». That becomes more nuanced when you expose iterators through your class API, but not the collection. There is no self awareness of invalidity in iterators, you can’t ask myiterator.isend() because an iterator can be a raw pointer; by principle of duck-typability, the C++ committee respected that an iterator implied interface is no more than the one of a raw pointer, and for good reason. So using optional here, decorates the iterator and gives it the ability to know its own validity, all problems nicely solved.

Anti canonical practices

#if platform
This is one of the worst offenders because of its pernicious presence in practice. This effectively multiplies your cyclomatic complexity with little mandate to do so. (meaning now you have 2*N tests instead of N tests to run)
It can be alleviated by leveraging libraries, rely on canonicalizing API like QT, boost.filesystem and whatnot, to avoid shouldering the cost of that cyclomatic complexity multiplication.
In general anything with a if is a smell to me. Especially introducing if checks for error cases. Error cases are not important enough to bloat your code. That’s by definition of the Zen of python. There are many discussions, still today, about Tony Hoare’s billion dollar mistake, about monadic error handling, about exceptions, or the std::expected proposal. All happenning because they recognize this same truth: that defense creeping in code is a bad-thing™.
Sometimes error cases are actual normal path of the business requirement; like in compilers, anything ending with a diagnostic, is mandated by specification; has a test, and deserves a if. But you see, there is a difference between a legitimate if that’s justifiable because it covers a mandated case in the original problem’s state machine; and an illegitimate if that’s just there because a particular implementation failed to canonicalize, or streamline errors.
Defensive programming is justifiable only when it is hidden at the level of expressiveness of interest. That means e.g, in C++ when you access an index through operator[], the defense is hidden in the implementation of that operator. Therefore you don’t have to cover your access with if (index = len) return ERROR; Because the operator will assert deterministically internally, so it’s guaranteed you’ll catch the problem at QA; all-the-while reaping the benefit of pure code at the call site level. This is true of null access too by the way. You can branch, only when accessing-out-of-bounds has a deserved fallback (e.g: is within the invariants of your program, or the function’s predicate in aspect oriented programming).

Uniform initialization

You know, the stuff that replaces constructor call with brackets. It is also part of MOP since it syntactically enables duck typing of construction calls for any kind of objects. It matters in templates.

JSON example

The wrong way to do it:
Nim:

import json
let jsonNode = parseJson("""{"key": 3.14}""")
doAssert jsonNode["key"].getFloat() == 3.14

Because now, what do you do when you have a slightly more complex access path, you want to factorize it, but potentially you have multiple types as clients.

float MyHelperGetKeyFloat(midpath)
{
jsonNode = ... obtain node
return jsonNode["stuff/nested/" + midpath + "/key"].getFloat();
}

double MyHelperGetKeyDouble(midpath)
{
jsonNode = ... obtain node
return jsonNode["stuff/nested/" + midpath + "/key"].getDouble();
}

And this non-genericity bubbles up to the highest client. In that situation, you’re now forced to return a json node to respect DRY. And now you leak an abstraction; and create un-necessary coupling. It now looks like jsonNode should use Interface Segregation Principle, and have a .getAny() which returns a variant type. But it’s a library, so no control over it.

The correct way:
https://github.com/nlohmann/json

json j;
// add a number that is stored as double
j["pi"] = 3.141;
// add a Boolean that is stored as bool
j["happy"] = true;

The channel to communicate type information has shifted from naming, to the type system. I don’t know about you, but to me, it sounds a bit better than a typing system should handle type stuff, and names should handle naming stuff. Thanks to that superior API, you are now enabled to work with factorized generic code.

This applies in the graphic world, for shader constant API too.
1:

SetFloat(f);
SetMatrix(m);

?
wrong.
2:

Set<Float>(f);
Set<Matrix>(m);

?
better, but over-constrained (hyperstatic). This can be useful when you actually desire this constraint, like a mechanical structure, it can be on purpose to increase solidity. But using the naming channel (example 1) for that purpose is a misguided, imposed, loss of opportunity for clients.
When useful (duck typing situations), find isostatism by leveraging type deduction:

Set(f);
Set(m);

Exactly as nlohmann’s Json is doing. The type information flows through the channel of the typing system, not the naming.

pushing it even further with yet inexistant language features

Uniform Function Call Syntax

With UFCS you can enhance this whole MOP rant to a new level. Nim has it and culturally the community makes extensive use of it. D has it. And Rust has a lesser version of it too.
This: "string".slice(2) is the same as slice("string", 2) and the very Nim-ic: 10.times (check it more in depth at https://hookrace.net/blog/what-is-special-about-nim/)
That syntax flexibility is paramount in a world with macros (lisp macros, not defines), or universal templates (like C++ has) to activate MOP.
Had we had UFCS, it might have been unnecessary to introduce a canonicalizer such as std::invoke.

Last word example

Let’s take a Yaml serializer, say you have:

struct S { string name; };
std::vector<S> m_esses;

and you want to serialize it to yaml. It’s natural to write a function:

string ToYaml(std::vector<S>& esses)
{
   return "{" + join(esses.begin(), esses.end(), [](auto&& elem) { elem.name }, ", ") + "}"; // whatever
}

Mistake. Why restrain to vectors ? your clients could have list, that would work the same for that implementation, and yet be forced into implementing a new version of that function ? Or they could want to yaml-ify only have of their vector. They’d have to copy that half. We saw it in the previous paragraph, the correct API here is ranges. We will assume a range is a pair of iterators, as chosen in stdlib algorithms pre C++20.

So it becomes:

template< typename IterType>
string ToYaml(IterType begin, IterType end)
{
  return "{" + join(begin, end, [](auto&& elem) { elem.name }, ", ") + "}";
}

Awesome. now you have duck-typability, because any collection that join supports, will work. Your ToYaml respects MOP (it forwards the limitations to join). But now  elem.name worked only on type S, and suddenly you have a struct T that you want to serialize too.

struct T { int id; };

template< typename IterType>
string ToYaml(IterType begin, IterType end)
{
  return "{" + join(begin, end, [](auto&& elem) { std::to_string(elem.id) }, ", ") + "}";
}

great but now you have a compile error because of redifinition. So…

template< typename IterType>
string SToYaml(IterType begin, IterType end)
{//... impl as before
}
template< typename IterType>
string TToYaml(IterType begin, IterType end)
{//... impl as before
}

?
NO ! that is not MOP compliant. Because now your implied interface is heterogeneous. which means your clients have to know what they are working on to chose the good function.
If they were methods of classes S and T that would be an equally problematic choice, because we don’t have UFCS, therefore the instance.ToYaml() syntax would break MOP as well. Who said you’re serializing things that have this method ? Now stuff that has free functions (e.g aggregates, fundamentals…) should be called by ToYaml(thing); and User Defined Types that can do it by themselves should do stuff.ToYaml() ? no ! it’s not canonical → not MOP. The solution, is to use SFINAE to split the definitions.

template< typename IterType, CONSTRAINT_HERE >
string ToYaml(IterType begin, IterType end)
{//... impl as before
}
template< typename IterType, CONSTRAINT_HERE >
string ToYaml(IterType begin, IterType end)
{//... impl as before
}

So what is the constraint ? it’s IterType::value_type is_same as S for the first case, and is_same as T for the second case. full expression:

#define SFINAE_IS_SAME(DependentTypeToCompare, ExpectedType)\
    enable_if_t< is_same_v<typename DependentTypeToCompare, ExpectedType> >* = nullptr

template <typename IterType, SFINAE_IS_SAME(IterType::value_type, S) >
string ToYaml(IterType begin, IterType end)
{ ... }

template <typename IterType, SFINAE_IS_SAME(IterType::value_type, T) >
string ToYaml(IterType begin, IterType end)
{ ... }

Now you’re good. you have a unified implied interface → MOP !

This is it

The reason why I chose the term opportunity, is because instead of designing ad-hoc for the problem at hand and nothing more, you are designing for 2 things, the problem at hand AND opening opportunities for other parts, or future parts of the system. When you make a function take a range and not a particular collection, you are opening opportunities for all sorts of clients.
This is yet another lego intervention; where imbrication (interoperability) is put on a pedestal, but at the level of the syntax and the typing system.
All these little practices together help me respect the “principle of maximum opportunity“. I found that applying them, together with other practices, like functional paradigm and reasoning about invariants (and all the stuff listed at the top of the article), plus a tiny bit of over-engineering at the corners, served me with happy surprises down the road of programming projects. Like having a long standing and forgotten TODO be naturally fixed by a refactoring that closed the completeness of a system. Or having enemy planted defense turrets, shoot at you out of the box even though you didn’t program that behavior explicitly (in my little game extreme carnage).
It enables unforeseen compatibility between parts of code you hadn’t consciously designed to work together. This really ups the mood when a requirement arises, and you realize you’ve already implemented it without knowing (or almost).
Another example of emerging feature happened when I was designing the separation of concerns between the main scene edition software, and real time rendering of viewports, in e-on software’s Vue suite (from Vue7). This is an equivalent refactoring as to apply MVC pattern. After weeks of pushing that paradigm, passing messages, decoupling life-times of objects, activating safe separation of threads… it got to a point where the rendering loop got so decoupled from the interface that it was free to get as late as heap would allow. And the visual response got laggish and delayed. In this case it was an undesired effect, but it’s a miracle to get such a separation to work at this level at all, while never putting any conscious design toward that end. Of course when it happened it was easily tamed with a condition variable to resynchronize the two; but the point to take here, is it’s better happening this way than the other (desiring it but having to work to get it).
Here is a great article that mentions the importance of MOP, in the development of Age Of Empires Definitive Edition: http://richg42.blogspot.com/2018/02/some-lessons-learned-while-developing.html
He doesn’t mention MOP, but that’s what he is talking about without having the language to put a word on it.
And yet, I noticed that elephants can’t cross shallow waters, while crocodile can. But this feels arbitrary and definitely smells of a if (entity.kind == crocodile) somewhere in the code: an anti canonical behavior. Or worse even, separated collections ?
Finally personally, the principle of maximum opportunity is a big part of the fun of doing this job. Because when you are rewarded with features that come from emergent behavior, it feels like Christmas.