I came upon an example of closures in Go here:
https://gobyexample.com/closures
It gives a pretty straight-forward example of closure scoping in Go. I changed how i is initialized from "i := 0" to "i := *new(int)".
func intSeq() func() int {
i := *new(int)
return func() int {
i += 1
return i
}
}
func main() {
// We call `intSeq`, assigning the result (a function)
// to `nextInt`. This function value captures its
// own `i` value, which will be updated each time
// we call `nextInt`.
nextInt := intSeq()
// See the effect of the closure by calling `nextInt`
// a few times.
fmt.Println(nextInt())
fmt.Println(nextInt())
fmt.Println(nextInt())
// To confirm that the state is unique to that
// particular function, create and test a new one.
newInts := intSeq()
fmt.Println(newInts())
}
The output of this is still 1, 2, 3, 1. Does the variable 'i' in intSeq() not get reallocated everytime nextInt() in main() is called?
Take a look at how you implemented intSeq.
func intSeq() func() int {
i := *new(int)
return func() int {
i += 1
return i
}
}
The initialization of i is outside of the function it returns.
So the only time a new pointer is allocated is when you actually call intSeq.
Since you are doing that just two times, that's how many different pointers you got.
That explains why the value is not reset when you just call nextInt (note that executing nextInt means just executing the function returned, which looks like:
func() int {
i += 1
return i
}
That would not reset the value of i but rather keep incrementing it (until you create a new one by calling intSeq again).
I hope that clarifies.
No it doesn't. That's the point of the closure. You are initializing an integer variable and storing it on the heap for use by the function the intSeq() function returns. There is no variable initialization happening in the nextInt() function
You will get a new function that uses a new sequence counter starting at 0 for each call to intSeq()
Edit: to add to this this is a bad way to get the current behavior. A better way would be to create a new sequence type that contains the method nextInt() int. E.g.:
type Sequence struct {
counter int
}
func (s *Sequence) nextInt() int {
s.counter++
return s.counter
}
func main() {
intSeq := new(Sequence)
fmt.Println(intSeq.nextInt())
fmt.Println(intSeq.nextInt())
fmt.Println(intSeq.nextInt())
}
There is no point in doing i := *new(int). That line says:
Allocate a new int
Create a pointer to it
Dereference the pointer
Assign the value to i
This is no different from i := 0 or var int i, but there's the extra step in the middle of creating, dereferencing, and discarding the pointer that never gets used.
If you want a pointer to an int, use i := new(int). *new anywhere is a pointless invocation and a code smell.
Related
I'm coming from an Scala background, and in Scala, you could define functions both as a single value, or an actual function, for instance:
val inc1: Int => Int = _ + 1 // single FUNCTION value
def inc2(x: Int): Int = x + 1 // normal function definition
// in this case "inc1 eq inc1" is true, since this is a single instance
// but "inc2 eq inc2" is false
And these 2 have some differences (i.e., size allocation, first one is a single instance, while the other one returns an instance each time it is invoked, ...), so based on the use case, we could kind of reason which one to use. Now I'm new to golang, and wanted to know if the below 2 function definitions (correct me if I'm wrong with the phrase) differ in Golang, and if so, what are differences?
var inc1 = func(x int) int { return x + 1 }
func inc2(x int) int { return x + 1 }
Thanks in advance!
Scala borrows a lot from functional programming. Go does not.
(If you've used multiple other programming languages, you should definitely read the Go specification. It's not very long as Go is not a very large language, although the new generics definitely complicate things a bit.)
In Go, the func keyword introduces a function definition or function type, with the details being context-dependent. The var keyword introduces a variable declaration.1 So:
func inc2(x int) int { return x + 1 }
defines a function, inc2, whose code is as shown. But:
var inc1 = // ...
declares and then initializes a variable, inc1. The type and initial value of the variable are determined by the commented-out section, so:
var inc1 = func(x int) int { return x + 1 }
defines a function (with no name) whose code is as shown. That function is then assigned to the variable as its initial value, so that the implied type of the variable is func (int) int or function taking one argument of type int and returning one value of type int.
Having created a variable, you can now either call the function currently stored in that variable:
func callit(arg int) {
result := inc1(arg)
// ... do something with the result ...
}
Or you can assign a new value into the variable, e.g.:
func overwrite() {
inc1 = func(a int) int { return a * 2 } // name `inc1` is now misleading
}
Because inc2 is a function, you can't re-assign a new value to it: it's just a function, not a variable.
1Note that a variable declaration with an initialization can use the "short declaration" form:
func f() {
v := 3
// ...
}
where we leave out the type and just say "use the type of the expression to figure out the type of the declaration". This declares and initializes the variable. Short declarations can only appear in block scope, so these must be inside some function. Other than omitting the var keyword they do nothing that you couldn't do by including the var keyword, or sometimes multiple var keywords:
result, err := doit()
might require:
var result someType
var err error
result, err = doit()
when written without using the short-declaration form.
Call to defer produces different results for variables declared in two different ways
package main
import (
"fmt"
)
func c(i int) int {
defer func() { i++ }()
return i
}
func c1() (i int) {
defer func() { i++ }()
return i
}
func c2() (i int) {
defer func() { i++ }()
return 2
}
func main() {
fmt.Println(c(0)) // Prints 0
fmt.Println(c1()) // Prints 1
fmt.Println(c2()) // Prints 3 Thank you icza
}
https://play.golang.org/p/gfnnCZ--DkH
In the first example i is an (incoming) parameter. At the return statement the return value is evaluated, and the deferred function runs after this, and incrementing i in that has no effect on the return value.
In the second example i is the name of the result parameter. At the return statement you explicitly return the value i, which is then assigned to the return value i (this is a no-op). But deferred functions are allowed to modify the values of the return "variables", and if they do so, that will have an effect on the actual returned values.
This becomes clearer if we add another example:
func c2() (i int) {
defer func() { i++ }()
return 2
}
This function will return 3, because the return 2 statement will assign 2 to i, then the deferred function will increment this, and so the return value will be 3. Try this one on the Go Playground. Relevant part from the Spec: Return statements:
A "return" statement that specifies results sets the result parameters before any deferred functions are executed.
In general, if a function (or method) has named result parameters, the return values will always be the values of those variables, but must not forget that a return statement may assign new values to these result paramteters, and they may be modified by deferred functions after a return statement.
This is mentioned in the Spec: Defer statements:
For instance, if the deferred function is a function literal and the surrounding function has named result parameters that are in scope within the literal, the deferred function may access and modify the result parameters before they are returned.
It is also mentioned in the blog post Defer, Panic and Recover:
Deferred functions may read and assign to the returning function's named return values.
And also in Effective Go: Recover:
If doParse panics, the recovery block will set the return value to nil—deferred functions can modify named return values.
See related question: How to return a value in a Go function that panics?
I have some code which is supposed to increment a count.
Here is the struct containing the count variable:
type PipelineData struct {
nodeData map[string]map[string]int
lastBurstResults map[string]map[string]string
burstReady map[string]bool
lastExecutionTime map[string]time.Time
currentNodeSize uint64
}
As you can see there is a member entitled currentNodeSize. This variable is intended to increment ever time the function addNodeData is called. You can see that the function addNodeData calls the function addCount which then uses an atomic incrementer.
func (p PipelineData) addNodeData(key string) {
nodeSlot := clusterScenario.GetNodeSlotByHashSlot(key)
i:=p.nodeData[nodeSlot][key]
i++
p.nodeData[nodeSlot][key]=i
p.addCount()
fmt.Println("Adding node count ",p.currentNodeSize)
}
func (p PipelineData) addCount(){
atomic.AddUint64(&p.currentNodeSize, 1)
}
Unfortunately, when I run this:
p.addNodeData("{pipelinetest}.key");
p.addNodeData("{pipelinetest}.key");
p.addNodeData("{pipelinetest}.key");
p.addNodeData("{pipelinetest}.key");
p.addNodeData("{pipelinetest}.key");
p.addNodeData("{pipelinetest}.key");
Dump(p.currentNodeSize)
The output is 0.
Here is the initialization of the PipelineData struct:
p = &PipelineData{
nodeData:make(map[string]map[string]int,0),
lastBurstResults:make(map[string]map[string]string,0),
burstReady:make(map[string]bool,0),
lastExecutionTime:make(map[string]time.Time,0),
currentNodeSize:0,
}
for i,_ := range clusterScenario.masterNodes{
p.nodeData[i]=make(map[string]int,0)
}
I understand the community has asked me to do my research. I'm not sure what to do at the point. Any help would be appreciated.
I also tried a general incrementor using a variable and that produced the same result which is why I tried an atomic incrementor
addCount takes a value receiver, not a pointer, so it's operating on a copy of the struct, incrementing the field of the copy and then discarding the copy. Change it instead to take a pointer:
func (p *PipelineData) addCount(){
This should resolve your issue.
Is this Get method buggy and prone to a theoretical data race?
type item struct {
val int
mutex sync.RWMutex
}
func (i *item) Set(val int) {
i.mutex.Lock()
defer i.mutex.Unlock()
i.val = val
}
func (i *item) Get() int {
i.mutex.RLock()
defer i.mutex.RUnlock()
return i.val
}
I ask because I saw a rare data race when running my tests with -race with the former code, but can't find any way of duplicating the effect.
Is it possible for i.val to be set to a different value between when the defer carries out the RUnlock, and when we read and return the value from the struct?
Must Get() be something like this instead?:
func (i *item) Get() int {
i.mutex.RLock()
defer i.mutex.RUnlock()
val := i.val
return val
}
Your code is safe, deferred functions are executed after the expression list of the return statement is evaluated. If you would have named result parameters, the return values would also be assigned to them before calling the deferred functions (and you could even modify the return values before "truly" returning from the enclosing function).
No need to create a local variable to store i.val.
My question is about the different named return value vs normal return value.
my code
package main
import "fmt"
func main() {
f := fmt.Println
f(a())
f(b())
}
func a() int {
i := 0
defer func() {
i += 1
fmt.Println("a defer : ", i)
}()
return i
}
func b() (i int) {
i = 0
defer func() {
i += 1
fmt.Println("b defer : ", i)
}()
return i
}
the result:
the a function return 0
the b function reutrn 1
Why?
The named return value also allocates a variable for the scope of your function.
func a() int: While you already return the value of i = 0, but since no named values was defined the static value got returned. So even though you're increasing i in the deferred function it doesn't affect the returned value.
func b() (i int): The variable i is allocated (and already initialized to 0). Even though the deferred function runs after the i = 0 was returned the scope is still accessible and thus still can be changed.
Another point of view: you can still change named return values in deferred functions, but cannot change regular return values.
This especially holds true in the following example:
func c() (i int) {
defer func() {
i = 1
fmt.Println("c defer : ", i)
}()
return 0
}
defer runs a function after the return statement but before the function is auctually returned, thus enabling modify returned results. However, only named return results can be accessed normally, i.e. by the variable name.
The return statement, when not naked (another thing about named return, but irrelevant here), the expression got evaluated. And if the return is named, the named variable is assigned with the evaluated value.
In your code, in func a() int the return is typed but not named. So when return i is execuated, it sets the return value, a variable not available to the code, as the value of i. You can consider it as RETVAL := i. And later, your deferred function modified i but the return value (RETVAL) remains unchanged.
But in func b() (i int), i is a named return. Thus, when return i execuate, it literally translate to i = i. And later, your deffered function modified i, a return value, so the returned value change.
More on return: https://golang.org/ref/spec#Return_statements
With the named return value you directly modify what gets returned, with the "normal" return value you just modify local variable in the scope of your function, which never gets returned.
More on this:
Deferred function can access named return values but it has no return value itself - so this is actually the only way to modify main function results from there. Very useful thing.
Imagine you want to fix code which panics - you want it to return the error instead. You can solve it by using recover in a deferred function and then assigning recovered error to named return value.
Example, somewhat abstract but hopefully useful:
func noMorePanics() (err error) {
defer func() {
if r := recover(); r != nil {
err = r.(error)
}
}()
potentiallyPanickingFunction()
}