Additionally, this feature complement new generic feature, this feature will help anyone that trying to use functional programming pattern (like monad pattern) in their code
On Tuesday, July 7, 2020 at 6:52:31 AM UTC+7 Kurniagusta Dwinto wrote: > 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/c75305e2-27e4-4a33-9111-d5b1c54eb9c9n%40googlegroups.com.