In my opinion, it's even more useful to the programmer to know that a
function is pure, than it is to the compiler. If checked by the compiler,
the annotation is also useful to ensure that the function remains pure as
it is modified over time.
On Fri, Dec 14, 2018 at 2:57 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Fri, Dec 14, 2018 at 9:51 PM Michael Jones <michael.jo...@gmail.com>
> wrote:
>
>> There is no absolute reason why a, b, and c could not be evaluated at
>> compile time.
>>
>
> Being pure is not enough for that. You need at least pure and total -
> otherwise you could have
>
> pure func Foo(x int) int {
> for {}
> return x
> }
>
> However, (dis)proving totality is not possible (not even touching on the
> fact that totality alone isn't even enough, when you also want speedy
> compilation). So to actually get this to work, you'd need to restrict pure
> functions to a non-turing-complete subset of Go (that is still useful),
> which is pretty complex to do.
>
> Especially given that the cases you mention (and all the cases I can think
> of where I'd definitely want that to happen) are just inlining + constant
> folding (+ maybe common subexpression elimination), Ians suggestion of
> keeping this a compiler optimization seems more sensible.
>
>
>> There are many practical reasons why it cannot be done today.
>>
>> 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:
>>
>> "if package is a standard one (like math) and the function is a pure one,
>> then call func on argument and use the result here"
>>
>> Doing this for user packages brings up deeper issues and is harder.
>>
>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@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.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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.
>
--
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.
