3 ms·
What does this get you that you don't get by putting an unexported method in your Go interface today? Honest question, since I'm not 100% sure I'm sharing the t
by jerf 5y ago
What does this get you that you don't get by putting an unexported method in your Go interface today? Honest question, since I'm not 100% sure I'm sharing the terminology of the author, and I don't know if this is a matter of the author being unaware of this possibility, or aware and not satisfied for some reason I don't understand.
You don't get a literal enumeration of all implemented types in the interface specification itself, but it's still trivial/mechanical to extract all implementations of such an interface with some code tool, and no external package can add to the list.
(Since I've learned from experience this always comes up: If you put a method named 'unexported' on your interface, it doesn't matter if a value in some other package creates a method called 'unexported', the compiler will not consider it a match. An interface in some package with an unexported method can not be implemented by any other package.)
- renlo 5y agoI think a difference is that current behavior is to check the interface at runtime vs static check ensuring that the interface's underlying value is one of those types. Have personally seen a number of bugs (ie panics) from the runtime checks
- ben0x539 5y agoIn this proposal, the compiler will yell at you if you switch over the contained type of a value of the interface type and don't have a case for each possible type.