> this seems like an eyesore and maintenance concern. (...) it does cause me to hear code review sirens going off in the distance.
Then why would you want to use currying in Go at all? What's the point of being able to write f(1)(2)(3) instead of f(1,2,3) *in a non-functional language?* Especially if the price you pay is code that is hard to read and difficult to maintain. As a Go proverb <https://go-proverbs.github.io/>says, "Clear is better than clever". On Friday, June 17, 2016 at 12:00:43 AM UTC+2, Zauberkraut wrote: > > Hello, > > Go enables the evaluation of functions using currying over function > literals. Every example I've found of this is rather shallow; a "deeper" > example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows: > > func f(x int) func(int) func(int) int { > return func(y int) func(int) int { > return func(z int) int { > return x*x + y*y + z*z > } > } > } > > Go's limited type inference makes the explicit, cascading function types > necessary; this seems like an eyesore and maintenance concern. While I > don't really mind it, it does cause me to hear code review sirens going off > in the distance. Generally speaking, would an extended usage of this > paradigm be considered unidiomatic in Go? Obviously, the above example is > contrived and not the sort of use case in question. Thanks! > -- 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.
