It avoids confusion AND silent errors. Imagine you have: func f() (int, int) func g() (int, int) func h(int, int, int, int) int
And somewhere in your code this line appears: v = h(f(), g()) But for some reason, someday you need to change your code and now your function f and g have the following signature: f() int g() (int, int, int) Then if what you suggest was allowed, the line v = h(f(), g()) would still compile --> h takes four arguments, and f and g have a total number of return values of 4. However, there has been a major change in the way things work: do you really want your compiler to say nothing and keep doing its thing? I don't think so. Moreover, in a real project, there's only a small chance f, g and h are in the same file (or package), which makes it even likelier that you will never see this (silent) error. Hope this helps! Le mer. 7 août 2019 à 17:09, <howardcs...@gmail.com> a écrit : > On Wednesday, August 7, 2019 at 8:45:18 AM UTC-5, lgo...@gmail.com wrote: >> >> f( g() ) compiles when g returns exactly the number of args that f() >> requires, but if g() returns only 1/2 that number f (g(), g() ) wont >> compile !! ...Is this not a Golang absurdity ?? >> >>> >>> > Eh. Certainly absurd from the perspective of a lot of languages, and > frustrating when put up against the otherwise good support for duck-typing. > But the sharp limitation of 'magic' in syntax and the emphasis on being > explicit where there might be ambiguity seems in line with Go's ethos to > me. > > At any rate, you can do almost this, if you really, really want to for > some reason. > https://play.golang.org/p/90gx-tHXwq5 > > It would be f(h(g,g)) instead of f(g(),g()), but if you had some situation > where you legitimately needed to make the call a lot, maybe it might be > worth it over putting the variable collection in each call site. > > On the whole, though, it really seems like trying to shoehorn a different > language's behavior into Go, and maybe you might be better off just finding > a different way to express the pattern. > > For example, instead of returning x and y from your scalarmult(scale, x, > y) function, you could use a Point struct. > > https://play.golang.org/p/V1Iw5HUK4e_- > > type Point struct { > x, y int > } > > func scalarMult(scale int, a Point) Point { > return Point{a.x*scale,a.y*scale} > } > > func add(a Point, b Point) Point { > return Point{a.x+b.x,a.y+b.y} > } > > func main() { > m1 := scalarMult(16,Point{28,33}) > m2 := scalarMult( 1,Point{28,33}) > r := add(m1, m2) > fmt.Println(r) > } > > {476 561} > > > Howard > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/9efbd578-8258-4d5f-a47a-5ac72ea609aa%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/9efbd578-8258-4d5f-a47a-5ac72ea609aa%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANgi337b0RYZDXaFjjmHhwktud4qVw1wFioftTUYizxaOL1oZA%40mail.gmail.com.
