On Wed, Sep 12, 2018 at 7:49 AM Ian Lance Taylor wrote:
> On Tue, Sep 11, 2018 at 5:38 PM, Patrick Smith
> wrote:
> > First, please consider requiring the 'type' keyword in definitions of
> > methods on generic types:
> >
> > func (x Foo(type T)) method() {}
> >
> Interesting idea, but even if w
On Tue, Sep 11, 2018 at 5:38 PM, Patrick Smith wrote:
>
> First, please consider requiring the 'type' keyword in definitions of
> methods on generic types:
>
> func (x Foo(type T)) method() {}
>
> This adds a small amount of verbiage, but makes the intent crystal clear. It
> also allows for easy e
On Tue, Sep 11, 2018 at 6:56 AM wrote:
> 2. An initialized type cannot be used directly as a method receiver, it
> must be type-aliased first:
> type FooInt = Foo(int)
> func (fi FooInt) Bar() {} // no type parameters now so clearly a
> method of FooInt
>
...
> Another problem is whether
On Tue, Sep 11, 2018 at 10:45 AM Ian Lance Taylor wrote:
> On Tue, Sep 11, 2018 at 10:04 AM, roger peppe wrote:
> >> func (x Foo(int)) Bar() {}
> >
> > As I understand it, this would be technically allowed, but would not
> > mean what you think.
>
> Yes.
>
Ouch! I chose a poor example. I think
On Tue, Sep 11, 2018 at 5:46 PM, Ian Lance Taylor wrote:
>
> While methods can be a convenient way to organize code, their only
> real semantic meaning is to satisfy interfaces.
They also represent a limited form of type-directed function overloading. A
package can contain multiple methods with
On 11 September 2018 at 22:46, Ian Lance Taylor wrote:
> On Tue, Sep 11, 2018 at 1:39 PM, roger peppe wrote:
>> On 11 September 2018 at 18:04, roger peppe wrote:
>>> If it were not explicitly prohibited by the draft proposal, we could
>>> also imagine this, a definition of a method foo on the ty
On 11 September 2018 at 22:17, jimmy frasche wrote:
> I think it would work with interfaces if the interfaces (generic or
> not) can themselves specify generic methods, like
>
> interface {
> Foo(type T)(T) T
> }
The problem with that is, as is pointed out in the draft proposal,
that if you all
On Tue, Sep 11, 2018 at 1:39 PM, roger peppe wrote:
> On 11 September 2018 at 18:04, roger peppe wrote:
>> If it were not explicitly prohibited by the draft proposal, we could
>> also imagine this, a definition of a method foo on the type A that's
>> parameterised with type T; the method itself h
I think it would work with interfaces if the interfaces (generic or
not) can themselves specify generic methods, like
interface {
Foo(type T)(T) T
}
You need to be able to invoke methods on a generic type where the
method is not specialized for the instantiation so I don't see why it
should cau
Can't say I've a strong feeling one way or another on that though there'd
be an awful lot of brackets if it were allowed!
You can, of course, always work around it with a top level function:
func foo(type S, T)(a A(T), s S, t T)
On Tuesday, September 11, 2018 at 9:39:23 PM UTC+1, rog wrote:
>
That'd mean more difference between parametrized and non generic types, which
causes more confusion than good.
--
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 g
On 11 September 2018 at 18:04, roger peppe wrote:
> If it were not explicitly prohibited by the draft proposal, we could
> also imagine this, a definition of a method foo on the type A that's
> parameterised with type T; the method itself has a type parameter S:
>
> func (a A(T)) foo(type S)(s
Yes, adding methods to instantiated generic types would have some
similarities to (partial) template specialization in C++.
Having concluded that it was a bad idea anyway from the earlier discussion,
I'm glad it's not going to be allowed :)
On Tuesday, September 11, 2018 at 6:45:29 PM UTC+1, I
On Tue, Sep 11, 2018 at 10:04 AM, roger peppe wrote:
>> func (x Foo(int)) Bar() {}
>
> As I understand it, this would be technically allowed, but would not
> mean what you think.
>
> This is defining a method Bar on the Foo type, and "int" is declaring
> a name for the type parameter defined in t
> func (x Foo(int)) Bar() {}
As I understand it, this would be technically allowed, but would not
mean what you think.
This is defining a method Bar on the Foo type, and "int" is declaring
a name for the type parameter defined in the definition of Foo. That
name would shadow the global language
Generics itself is a form of overloading, albeit in a very narrow sense. A
generic function is in effect a set of functions (often infinite) where all
the type parameters are replaced by those types which can conceivably
satisfy any constraints placed upon them.
Anyway, assuming for the moment
On Tue, Sep 11, 2018 at 12:51 PM alanfo 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 overlo
I've been thinking some more about this and, assuming that Patrick and I
are right that an instantiated type can have its own method set, there are
going to be some severe ambiguities when defining generic functions i.e.
it's not always going to be clear whether T is a type parameter or an
actu
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.
On Tue, Sep 11, 2018 at 11:52 AM 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 Fo
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() {}
and that Foo(in
21 matches
Mail list logo
