LoggingContext with a phantom type parameter representing what kind of details are in it. If a function that accepts a LoggingContext is supposed to trust that the caller has already embedded all the relevant data that would be passed as arguments into the context, then you could say a function that accepts a LoggingContextOf will "trust, but verify" instead.

You can pick a tag to represent each kind of data you want to appear in a context. The use of + means the tag language in LoggingContextOf[Tag] reflects the subtyping relation built into Scala, and Any and with form the zero and append of a commutative monoid of tags.

A few, but not all, type-level implications of this:

• LoggingContextOf[Foo with Bar] is-a LoggingContextOf[Foo]
• LoggingContextOf[Foo with Bar] is-a LoggingContextOf[Bar]
• LoggingContextOf[Elephant] is-a LoggingContextOf[Animal]
• LoggingContext is-a LoggingContextOf[Any]

A context with a more specific scope will always be preferred in implicit resolution. So if you call a function demanding a LoggingContextOf[Foo] and you have two implicits in scope, a LoggingContextOf[Foo] and a LoggingContextOf[Foo with Bar] then the latter will be chosen, in accordance with SLS §7.2, §6.26.3. This fits well the "more context = better than" overall philosophy of the contextualized-logging library.