On Tue, Sep 11, 2018 at 12:51 PM alanfo <alan.f...@gmail.com> wrote:
> 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.
>
It could, if you're willing to go down the rabbit-hole of overloading.
Historically, Go has firmly stood against that.
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> 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.
>>> 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.
>
--
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.
