Quoting Bakul Shah (2018-12-14 16:11:51)
> > If a function was labeled as pure ("pure func ...") the compiler
> > would not even need think hard, and if purity were a reflectable
> > attribute, then it is imaginable that compiling a function
> > invocation could be:
>
> This would complicate the language unnecessarily in the name
> of optimization. Next on the slipper slope would be declaring
> parameters "pure" and then having two versions of things. e.g.
>
> func intReduce(func(x, y int)int, []int) int
>
> This can be evaluated at compile time if the given func is pure.
> Not worth it, IMHO.A lot of this can also probably be inferred by the compiler, and then be just part of the optimizer that isn't exposed to users. Functions only composed of pure operations are pure, and when a compiler spots this it can tag the function with some metadata, so it can tell when looking at a function at a call site whether it is pure. -Ian -- 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.
