On Tue, Sep 11, 2018 at 11:52 AM <alan.f...@gmail.com> wrote:
> I'm not sure whether this:
>
> type Foo(type T) struct{}
>
> would be allowed or not - the compiler might say "type parameter T is not
> used".
>
> Anyway, if it were allowed, then it would follow that these should also be
> allowed:
>
> func f(x Foo(int)) {}
>
> func (x Foo(int)) Bar() {}
>
I don't think this would follow at all. Specifically the latter IMO *can't*
be allowed and I don't see what allowing unused type-parameters has to do
with it.
and that Foo(int) would implement Barrable but Foo(float64) would not.
>
> My understanding of the draft design is that the following wouldn't be
> allowed unless V were a 'concrete' type:
>
> func (x Foo([]V)) Bar() {}
>
I don't see anything in the design that would allow using []V as a
type-parameter (as opposed to argument). In the design, AIUI, `func(x
Foo(T)) Bar() {}` declares a method on a generic `type Foo(type T …) …` and
the type-keyword in the method-declaration is left out as a shorthand.
FWIW, this is the section where method declarations are handled:
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#parameterized-types
Parameterized types can have methods. The receiver type of a method must
> list the type parameters. They are listed without the type keyword or any
> contract.
Note that type parameters are different from type arguments. The former is
the specification in the type/function declaration, the latter is what
generic types/functions are called with to instantiate. []V is not a valid
parameter (a parameter must be an identifier), it's only a valid argument.
Similar for `int` in OPs question: You can, of course, call a
type-parameter `int` (it's an identifier after all), but AIUI the question
is about using it in a method-declaration as a type argument to only
implement the method for some argument combinations.
So you'd need to write something like this for it to compile:
>
> type V int // or whatever
>
> Alan
>
> On Monday, September 10, 2018 at 9:02:40 PM UTC+1, Patrick Smith wrote:
>>
>> Under the generics draft, would this be allowed?
>>
>> type Foo(type T) struct{}
>>
>> func f(x Foo(int)) {}
>>
>>
>> I assume the answer is yes; I can't see any good reason to disallow it.
>>
>> What about this?
>>
>> func (x Foo(int)) Bar() {}
>>
>>
>> If this is allowed, does this now mean that Foo(int) implements
>>
>> type Barrable interface {
>>
>> Bar()
>>
>> }
>>
>>
>> but that Foo(float64) does not implement Barrable?
>>
>> What about this, where V is meant to be a type parameter, not a specific
>> type that was defined earlier in the code? (If allowed, it probably needs a
>> 'type V' in it somewhere, but I'm not sure where to put that.)
>>
>> func (x Foo([]V)) Bar() {}
>>
>> --
> 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.
