The whole point of an interface is to allow for multiple concrete implementations. What hidden requirements are you suggesting which would make the act of opting in to known working interfaces a good idea?
Separately, there's a bit of tension generally between authors wanting to limit promises made to callers and callers wanting to use any code that's good enough for their end application. Compile-time duck typing (implicit interfaces or structural typing or whatever) is a decent tradeoff for that. Something like a `fn ReadTwice(fn Read(string) int) fn (string) int` combinator almost doesn't care about your particular semantics, but that sort of generic code is impossible to write in a world with sealed classes, opt-in interfaces, and other sorts of features taking power away from callers (who have the appropriate context to know whether it's reasonable to use your code) and giving it to library authors (who want to support a narrow enough use case to guarantee their code is correct and tell everyone else to fuck off). Even just having two separate IReader interfaces or ISleeperClock or IClock or ITime or all the other sorts of permutations you might find in an ecosystem can cause major friction without actually adding any type safety.
> The whole point of an interface is to allow for multiple concrete implementations.
The issue is that in this case the second method may not be an implementation of the interface at all in the first place, simply a method that happens to have the same signature. That can happen easily when parameters are only built-in or BCL types.
Why does that matter though? Looking at the concrete `Read` example above, what semantics might apply to an IReader vs a class which happens to accidentally conform to the interface? If a person asked for an IReader argument and found your class instead, why would they be upset?
The whole point of an interface is to allow for multiple concrete implementations. What hidden requirements are you suggesting which would make the act of opting in to known working interfaces a good idea?
Separately, there's a bit of tension generally between authors wanting to limit promises made to callers and callers wanting to use any code that's good enough for their end application. Compile-time duck typing (implicit interfaces or structural typing or whatever) is a decent tradeoff for that. Something like a `fn ReadTwice(fn Read(string) int) fn (string) int` combinator almost doesn't care about your particular semantics, but that sort of generic code is impossible to write in a world with sealed classes, opt-in interfaces, and other sorts of features taking power away from callers (who have the appropriate context to know whether it's reasonable to use your code) and giving it to library authors (who want to support a narrow enough use case to guarantee their code is correct and tell everyone else to fuck off). Even just having two separate IReader interfaces or ISleeperClock or IClock or ITime or all the other sorts of permutations you might find in an ecosystem can cause major friction without actually adding any type safety.