> 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 built-in int type name, in the
same way that it's currently valid in Go to do this
(https://play.golang.org/p/fMwGrRnJEOt):
type int otherType
I don't see any ambiguity here.
Here are some possible forms of function and method definition. I've
used A, B, C for types defined at global scope, and S, T, U for type
parameters.
Define a function foo with an argument of type A. We're all familiar
with this one:
func foo(a A)
Define a method foo on type B with an argument of type A. This too, is familiar:
func (b B) foo(a A)
Define a function foo with a type parameter T:
func foo(type T)(a T)
Define a function foo with an argument type A(B); A is parameterised
with the type B, which is not itself a parameter type and must be
defined elsewhere:
func foo(a A(B))
Define a function foo with an type parameter T and an argument type A
parameterised with T:
func foo(type T)(a A(T))
Define a method foo on the type A that's parameterised with type T. T is the
local name for A's type parameter that can be used within the body of foo:
func (x A(T)) foo()
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 S, t T)
cheers,
rog.
On 11 September 2018 at 15:47, <alan.f...@gmail.com> wrote:
> 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 that I agreed with you that it was a bad
> thing for initialized types to have their own (non-generic) method set, the
> next question is how can you stop it?
>
> I suppose with solution #2 in my previous post, the compiler could 'look
> through' any type alias and disallow it when an attempt was made to declare
> a function with the type alias as receiver.
>
> You could still create a defined type rather than an alias:
>
> type FooInt Foo(int)
>
> but, presumably, there would be no problem in FooInt now having its own
> methods as they would be quite distinct from those of Foo(int).
>
>
> --
> 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.
