Personally I want to see Extension Interfaces, so you opt into such a system in a slightly more explicit way. The slightly extra work aides in tooling and documentation but I can see how Go's way is not absurd.

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.

In old-school C++ you would probably handle this with traits. I.e. a specialization of a tag type that can be written by either the class author or a third party that indicates a types semantic compatibility with a concept.

Example: specialising std::hash instead of forcing everyone to add hashCode() members

It’s essentially a less likely version of using the wrong callback, something which has undoubtedly happened in the fullness of time but is of no real concern.

No in my opinion the issue is the opposite: implicit structural interfaces make it harder to discover what interfaces a type implements, and what you can do with it.

A secondary effect being that mismatches have worse reporting, whether you’re trying to implement an interface or the interface has changed from under you the compiler only reports use site so from there you have to did out what the type is and why it does not conform anymore, things get worse if side casts are involved. There’s actually a pattern for checking conformance:

    var _ Iface = (*Type)(nil)

Oh yeah and if the interface removed a method and you didn’t realise you might be dragging that useless methods for a long while. Then again it’s not like your Java-style interface is any different.

If you consider that a problem, you would also have the same problem in any other language with first class functions. Someone might define a `readSomething(string -> int) -> ...` function. Does that mean everyone who now defines a `string -> int` function must make it suitable for `readSomething`? Obviously not. It's up to the caller to pass correct arguments to the functions they are calling.

That almost never happens in reality so it's not an issue.

For example, go has io.Reader which needs just `Read(p []byte) (n int, err error)`

Your issue is that you accidentally do Read with same signature, but it will mean something else, and the error it returns are different, so instead of EOF (as io reader should) it will return something else on end of file?

... it just doesn't happen in Go. You would need to go out of your way to break it. I guess it theoretically can happen.

> And my main fear: how do I know I use the right object? I would tempted to add methods all the time to satisfy the target interface instead of using another object that already satisfies that interface.

Why don't you do this with explicit interfaces? It's one extra line of code beyond the method implementation, and it's a backwards-compatible change. I suspect that the main reason you don't is because you know that class Foo shouldn't be a Bar, and the same logic can easily guide you with implicit interfaces.

> Not knowing explicitly whether I can use an object or not is confusing, or am I missing something obvious?

This one I'll agree with. Implicit interfaces work well in quick code that you're writing yourself that fits in your head. When you're trying to understand a library someone else wrote, though, being able to have the IDE list all the implementations of an interface is very valuable.

Also, explicit interface tagging communicates authorial intent in a way that isn't possible with implicit interfaces.

I think it's easier to think of Go as a mix of Python, Typescript, C++ and others, making sort of the same re-implementation that Java/C# originally did with a more modern approach. Please not that this is neither completely correct and opinionated, but I think it's a good way to explain it. Similarly I think Typescript is a better way to think of objects in Go than what you may be used to coming from C#. Stucts work much like Type/Interface in Typescript and you're not going to have issues with it because anything you change will be immediately obvious in your code. It also means your functions live in isolation from the objects, and this is perhaps one of the "weaker" parts of Go coming from C# because it won't be blatantly obvious when you're working with an object until you get the working behind = assignment and := declaration + assignment. On top of that you have the Go interface{} which isn't really comparable to a C# interface and it's much easier to think of it as the Typescript "Any/Unknown" type. This isn't exactly true because it's an unknown type where all you basically know is that it holds no methods, meaning that unlike the Any type in Typescript and somewhat similar to the Unknown type {} is actually useable in Go.

I don't think there is a good reason to chose C# for new projects if Go is an option for you. I don't think there is any reason to use Go if you plan on using C#, maybe because that is what your team does well. We did it because we needed coroutines easily and because most of our programmer aren't really C# programmers but Typescript programmers. We found it to be a delight to work with, however, but realistically I don't think there will a reason to adopt Go very often if you're big on C#/Java. At least unless the landscape of the talent pool changes into Go orientated, as it'll typically be much easier to hire and onboard people from C#/Java.

But yes, this idea is for the case where there's exactly one interface member, then it's equivalent to a function pointer.

The interface can have a comment documenting what it's supposed to do. Any class/function that explicitly implements said interface should adhere to that definition/meaning. Any function that implicitly implements it... who knows what was intended.

I'm not sure I understand your use case where you need to conflate the two. You want to enforce the contract but with arbitrary method names?

I suppose you could wire up something like this but it's a bit convoluted.

    interface IFoo {
     string F(String s);
    }
    
    class Bar {
     public string B(String s){
      return "";
     }
    }

    // internal class, perhaps in your test framework
    class BarContract : Bar, IFoo {
     public string F(string s) => B(s);
    }