Well, firstly, I think it would be perfectly reasonable for the compiler to
disallow a generic type if one (or more) of its type parameters were not
used in the generic type's definition. However, I couldn't see anything
about this in the design document itself which is why I said I wasn't sure.
Whilst you're correct that parameterized types can have methods, I don't
see any reason why instantiated types can't have methods as well, just like
any 'normal' concrete type.
However, you might be right that, in an expression such as Foo(int), `int`
would be regarded as a type parameter rather than the built-in 'int' type.
If that's the case, then you'd need to use a type alias to refer to the
instantiated type Foo(int) to remove the ambiguity.
In the case of Foo([]V), []V cannot possibly be a type parameter but it
could be a type argument (in the absence of a contract to disallow slices).
So I'd have thought - rightly or wrongly - that the compiler would infer it
to be an instantiated type in these circumstances.
Alan
On Tuesday, September 11, 2018 at 11:08:45 AM UTC+1, Axel Wagner wrote:
>
> On Tue, Sep 11, 2018 at 11:52 AM <alan...@gmail.com <javascript:>> 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...@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.
