Dependency injection resolution rules: which dependency should a parameter bind to?

[dornbirndevelops]

Hi all,

While working on #722 (fixing the exponential MSVC compile time with many reference dependencies, #715),
the proposed fix involved how sm looks up its dependencies.
The new lookup behaves differently in a number of edge cases.
None of them are documented and none were covered by tests.
So the review turned into a discussion about what the correct behavior is,
and so far we have opinions but no shared answer.

I don't think a compile-time fix is the right place to decide this, so I'd like to agree on the rules here first.
Once they're settled, we can:

1. document them,
2. add a test for every case,
3. make future changes follow them.

Terms

• dependency: an object passed to the constructor, sm<c> sm{x, y};
• parameter: what a guard, action or the state machine class asks for, [](const base& b) { ... }
• candidate: a dependency that may be bound to a parameter

Proposed principles

• P1: Never cast away const. A const dependency is never a candidate for a mutable parameter.
• P2: Never dereference a pointer. A pointer dependency never satisfies a reference parameter (it may be null). Taking the address of a reference dependency to satisfy a pointer parameter is fine.
• P3: An exact match beats derived-to-base. If a dependency of the requested class itself is passed (ignoring cv), it is used even when derived dependencies are passed too.
• P4: Derived-to-base only when unique. A derived dependency binds to a base parameter only if it is the only candidate and the base is public and unambiguous.
• P5: cv-qualifiers do not disambiguate. Two candidates that differ only in const/volatile are ambiguous. The user fixes this by requesting the concrete type.
• P6: Ambiguity is a compile error, never a silent pick. No "first one wins", no "the const one wins", no fallback to a default-constructed, dangling or null object.

This list is a starting point and certainly not complete. If you think a principle is missing, wrong or too strict, feel free to suggest changes so we can discuss them.