If we try to translate contracts into interfaces, the first thing we run
into is that there's no way to refer to the dynamic type of the interface.
Compare:
contract Fooer(t T) {
interface{ Foo() T }(t)
}
to
type Fooer interface {
Foo() ???
}
There would have to be some sort of self type:
type Fooer interface {
Foo() self
}
Let's say there's a built in convertibleTo constraint
type FooConvertible interface {
convertibleTo(int)
Foo() self
}
For one thing, this looks like a method. (Aside: This is a problem in the
existing generics proposal as well if generic interfaces are allowed, since
interface embedding would become ambiguous.) Presuming that we solve this
ambiguity, there's a deeper challenge. If I have a generic interface:
type Taker(type T) interface {
Take() T
}
In general, a given concrete type could only satisfy this interface one
way. Having
type IntAndFloatTaker interface {
Taker(type int)
Taker(type float)
}
wouldn't work because the same type can't implement both func (...) Take()
int and func (...) Take() float. convertibleTo (and convertibleFrom) would
be unique in this regard, and could get in the way of (say) being able to
infer the type parameters of
func Take(type T, U Take)(t T) U { t.Take() }
T can be inferred from the argument, and you ought to be able to infer U
from T, since T can only implement Taker(type U) for exactly one U. But, if
convertibleTo exists, this isn't true in general.
This doesn't address operators. You could have builtin constraints for each
operator, or each set of operators. Or you could have some sort of builtin
method corresponding to each operator. These are certainly doable, but
designing and naming the constraints/methods is a whole undertaking which
the contracts draft seeks to avoid.
On Tue, Sep 4, 2018 at 12:52 PM xingtao zhao <zhaoxing...@gmail.com> wrote:
> My five cents:
>
> 1) the methods of the type template are defined by interface style
> 2) operators are retrieved implicitly from function body
> 3) function-calls inside are also retrieved implicitly from the function
> body
>
> For graph example, we may declare it as:
>
> type Edgeser(type E) interface {
> Edges() []T
> }
> type Nodeser(type N} interface {
> Nodes() from, to N
> }
> type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
>
>
> On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>
>> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts
>> <golan...@googlegroups.com> wrote:
>> >
>> > Link: [Getting specific about generics, by Emily
>> > Maier](https://emilymaier.net/words/getting-specific-about-generics/)
>> >
>> > The interface-based alternative to contracts seems like such a natural
>> fit-
>> > It’s simple, straightforward, and pragmatic. I value those aspects of
>> Go’s
>> > philosophy and consider them to be features of the language, so it’s
>> > encouraging to see a solution that suits them so well. The author also
>> does
>> > a great job of contextualizing the use cases and debate around
>> generics,
>> > which I found incredibly helpful.
>> >
>> > Any thoughts?
>>
>> It's a very nice writeup.
>>
>> It's worth asking how the graph example in the design draft would be
>> implemented in an interface-based implementation. Also the syntactic
>> issues are real.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
