Why would you put generics on a method ?
The syntax you demonstrate is horrible, indeed.
what if generics are type related
type notFinal struct {
p1 <T1>
p2 <T2>
}
func (n notFinal) whatever(in <T1>) string {
return fmt.Sprintf(in) // anything to interface{}, works.
}
type Final notFinal<int, string>
Final.whatever(1) // "1"
//notFinal not instantiable, not type assertable
Or func related
type notFinal func(in <T1>) string
func Final notFinal<int>
Final(1) // "1"
That said, ultimately, the more the syntax is parametrized the more complex
it become. when there are many func signature as you demonstrate, it will
get worse.
Named type might help, could be vetted too ?
Also
none of this is as powerful as code gen.
None of those examples are better than interface{}.
On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two
> values: a first int, that we name z and an error named err. A little bit
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that
> receives x and y as int parameters, returning two values: a first int, that
> we name z and an error named err. Definitely not so simple.
>
> <genType1, genType2> func (r genType1) f(x, y genType2) (z getType2, err
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>
--
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.
