I’m not sure that is the best argument. If it was a major change most likely the return types have changed as well, especially if new values are added, and thus it still would not compile.
> On Aug 7, 2019, at 10:42 AM, Michel Levieux <m.levi...@capitaldata.fr> wrote: > > 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. > > -- > 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. -- 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/C52D93DD-0194-4734-8728-74D8D41890D8%40ix.netcom.com.