Adding pure marker will give information to the programmer that the
function will not do any side effect, the compiler just gives compile error
when the programmer disagrees about the contract, like doing IO operation
on pure function.
So in the end, this feature focuses on helping the programmer, not the
compiler, to make sure the function does not do any io operation inside it.
I like how Haskell separate IO and non-IO function, they create a clear
separation between those worlds,
On the other side, the compiler can evaluate some function in compile-time,
although this feature maybe not really needed yet, this will help the
programmer to create pre-computed value instead of copying some magic blob
data,
> I agree that adding the keyword would let the compiler enforce it, but
> that doesn't seem all that big a benefit to me. It also seems like
> something that could be done by an analysis tool rather than requiring
> a change to the language.
That wouldn't work with interfaces, like
purefunc Hai(x interface{}) int {
val := 42
if x, ok := x.(interface { pure Value() int }); ok {
val += x.Value()
}
return val
}
here, without knowing the implementation, the caller of Hai know that Hai
will not do any IO operation at all.
I've tried to create an analysis tool to do that before. I need to mark the
pure function with "Pure" suffix,
the code above will be
func HaiPure(x interface{}) int {
val := 42
if x, ok := x.(interface { ValuePure() int }); ok {
val += x.ValuePure()
}
return val
}
But when it comes to passing a function as a parameter, it will become more
subtle
purefunc Hai(x purefunc() int) int {
return 42 + x()
}
// this should generate a compile error
a := 20
fmt.Println(Hai(purefunc() int {
a += 1 // side effect
fmt.Println("something") // side effect
return a
}))
On Tuesday, July 7, 2020 at 5:56:23 AM UTC+7 Ian Lance Taylor wrote:
> On Mon, Jul 6, 2020 at 3:11 PM bugpowder <mit...@gmail.com> wrote:
> >
> > I'd guess the compiler could then enforce it (see if any non-pure marked
> function is called from a pure one), it could exploit it (e.g. play with
> evaluation order, cache, etc), and other such things?
>
> The compiler can already tell whether a function is pure, so I don't
> think that adding a keyword would lead to any better optimization.
>
> I agree that adding the keyword would let the compiler enforce it, but
> that doesn't seem all that big a benefit to me. It also seems like
> something that could be done by an analysis tool rather than requiring
> a change to the language.
>
> Ian
>
>
> > On Tue, Jul 7, 2020 at 1:00 AM Ian Lance Taylor <ia...@golang.org>
> wrote:
> >>
> >> On Mon, Jul 6, 2020 at 9:47 AM <kurnia...@gmail.com> wrote:
> >> >
> >> > Hi, I don't know if this kind of idea is already discussed before.
> >> >
> >> > I have an idea of adding pure function marker/type on golang, it is
> just like "constexpr" on C++ or "const fn" on Rust, whether this function
> is evaluated at compile time if the input is known at compile time is
> another discussion,
> >> > I don't think this idea is hard to implement
> >> >
> >> > to my understanding, a pure function is a function that doesn't have
> a side effect, so we can limit pure function to:
> >> > - unable to call non-pure function
> >> > - unable to modify a variable that is not declared on current
> function (like a global variable)
> >> >
> >> > for this purpose, we can think receiver as input to the function
> >>
> >> ...
> >>
> >> > what do you guys think about this idea?
> >>
> >> You didn't really explain what we would gain by adding this to the
> >> language. It's clearly already possible to write pure functions. How
> >> does it help to add the ability to explicitly mark a function as 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...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXOdCc8Zz8mXAmghLm%2B6%3Dvi8S8zG_3Phrv2Hy-w%3Dm70kQ%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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAACdnTAKTKQxU_K5xRqHGDKKBEhyTAq6%3D6q1HK%2BgDUewgJW1aw%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/a09a6843-c5dc-4da0-89ed-9499841ea0b4n%40googlegroups.com.
