On Mon, Jul 6, 2020 at 4:52 PM Kurniagusta Dwinto
<kurnia.d....@gmail.com> 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
> }))
Fair point about interfaces.
There are many many different attributes we could apply to functions
in Go. For example, one that is commonly requested is "this
function/method does not modify memory via this pointer," which in C
or C++ is implemented using the "const" type qualifier. It's not
obvious to me that "pure" is a characteristic that is important enough
to be singled out and added to the language. I suppose it might be
useful in some cases, but the test for whether something is worth
adding to the language is whether the benefit is worth the cost.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXXGttU4kyiNhuMQvHwNX%2B2i8kCx9HNejPv%2BT2UHWkziQ%40mail.gmail.com.
