4 ms·
Yeah, it looks like "contracts for homogeneous, interfaces for heterogeneous / pluggable" is a useful distinction. But what worries me is that it's an extremel
by JulianMorrison 7y ago
Yeah, it looks like "contracts for homogeneous, interfaces for heterogeneous / pluggable" is a useful distinction.
But what worries me is that it's an extremely subtle, implementation-understanding distinction. They are still extremely similar and their dissimilarity seems to be of the sort that will bite people. Beginners definitely, and sometimes even pros.
- ithkuil 7y agoI wonder: why not just accepting interfaces as contracts (a subset), e.g. literally allowing func Foo(type T fmt.Stringer)(T) T and allowing runtime values of type contract, e.g. contract SignedInteger(T) { T int, int8, int16, int32, int64 } func Foo(x SignedInteger) bool { return x > 0 } i.e. decoupling the runtime boxing vs the compile type parameter resolution from the "interface specification language". I do understand that the need for the new "contract" syntax becomes apparent when you have contracts over multiple variables, but that doesn't mean in the single type variable degenerate case there is no overlap. Perhaps embracing that overlap would help people understand more quickly where the actual difference is (in the way types and function signatures uses them, rather than what operations they describe)