On Tuesday, September 4, 2018 at 2:26:58 PM UTC-7, Steven Blenkinsop wrote:
>
> 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
>
> }
>
>
>
I was assume that generic interfaces are allowed, which we do not need
"self" type. In terms of convertableTo, it can be put into the operator
category, which will be implicitly retrieved from the function body.
> In general, a given concrete type could only satisfy this interface one
> way. Having
>
>
>
> type IntAndFloatTaker interface {
>
> Taker(type int)
>
> Taker(type float)
>
> }
>
I think this is still not allowed, as they have the same function name
while different types.
>
>
> 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.
>
As we do not have operator overloading, there are only a few sets of
operations for each type, for example Numeric, Addable, Hashable, Equality,
etc, and they can never be changed or extended. These are completely
hiden/invisible from user as operator constraints are retrieved implicitly.
So we do not have to name them.
The only thing a contract can do while interface can not, is that we can
not have constraints on structure fiels, as only methods are allowed in
interface.
>
> On Tue, Sep 4, 2018 at 12:52 PM xingtao zhao <zhaox...@gmail.com
> <javascript:>> 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...@googlegroups.com <javascript:>.
>> 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.
