Design to interfaces or Design to introspections

[via Digitalmars-d]

Back at dconf 2015, Andrei introduced design-by-introspection in 
his talk "Generic programing must go", he showed that not only 
classes have "class explosion" problems but so do templates.
The basic idea behind design by introspection the way I 
understand it is similar to the one  behind design patterns. One 
of the Gang of Four' two principles is "Favor object composition 
over class inheritance." i.e. inheritance must go, as Andrei 
would say.

Then I stumbled upon DIP84, which reminded me of the other GoF' 
principle "Program to an interface, not an implementation".
And I started wondering why would I ever write code like this:

     auto someAlgorithm(SomeInterface obj) { /* ... */ }

When I can do this:

     auto someAlgorithm(I)(I obj) if(isSomeInterface!I) { /* ... 
/* }

or more generically:

     auto someAlgorithm(I)(I obj)
     if(satisfiesInterface!(I, SomeInterface, SomeOtherInterface 
/*... etc */)
     { /* body ... /* }

This would be a modern design to introspection? that goes with 
the modern design by introspection.
While this approach has more code over the classic one, It has 
the advantage of working "natively" for both classes and structs 
(without dirty tricks like std.experimental.typecons.wrap does 
for structs), and would in the end save you a lot of code 
duplication, chaos and death if used along with 
design-by-introspection.

What do you think.