[jayd16]

But parameters don't just fall into FooBar shaped holes. Someone passes them in there. Its still an explicit choice by the programmer to not read the docs and just roll the dice. Who thinks "I fits, I sits" is sufficient for a proper program anyway? Is it really a downside to allow this kind of munging?

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.

[scratcheee]

That argument works pretty well for any bad api design (assuming sufficient documentation somewhere).

Yet I assume we can agree that regardless of how you can work around bad apis, good api design that prevents misuse is always better.

The safety measures have to stop somewhere of course (short of an api that is a single function which does exactly the thing you want without inputs or outputs, which seems unlikely), but extending type safety to interfaces does not seem like a step too far.

[jayd16]

Another aspect of the issue is to consider the asymmetric nature of knowledge of the API author and the API consumer.

When one authors a type in a language like C# they must predict how that type will be used and what interfaces the author promises the type can be.

The API consumer might be unfamiliar with the types in an API at first, but ultimately they will know more about how they want to use the type and what additional contracts they think the type fulfills.

As it is, this knowledge is only useful when inheriting a type. There is no facility to "vouch" for a type in C#, currently. In Go structural typing fulfills this.

I think Extension Interfaces is the best of both worlds.