Updated Closure instruction

[amaddio]

Added explanation that one has to align return types. It wasn't clear to me that not only a function but also the return types of that very function have to be specified. It is clear when you know it. But as a Go beginner you could stumble over it, expecially when you start using multiple return types e.g. (int, error)

[eliben]

I'm not sure I understand what "equal return types" means.

And what you mean by "align" in the PR comment...

Can you clarify what you're trying to show here?

[amaddio]

Sure. I wanted to clarify that it is not enough to just return a func type e.g.

// wrong; missing int return type
func intSeq() func() {
    i := 0
    return func() int {
        i++
        return i
    }
}

Secondly I wanted to add that the return type of the outer function must match the inner function.

// wrong; the outer function definition differs
func intSeq() func() int {
	i := 0
	return func() (int, error) {
		i++
		if i == 9223372036854775807 {
			return i, fmt.Errorf("the counter reached the maximum int number")
		}
		return i, nil
	}
}

I hope it makes more sense now. Pitty that my take was not comprehensible enough so it made sense at first sight. Do you have a better idea to describe it?

[eliben]

Thanks for clarifying.

I think the current text is ok unless we figure out a better way to say it.

As a general guideline, it's a non-goal of gobyexample to explain any nuance of the language's syntax. We assume the user read some basic tutorials and the Tour of Go already, and understands basic syntax and semantics.

[amaddio]

Gotcha. My bad then. Didn't know that because some basic syntax was explained in other parts as well like here:

I just wanted to share my experience what occurred to me when I ran over the examples and tried to implement them myself. To document that func is not a valid return type in case the wrapped function returns or expects parameters.

[eliben]

But that's the thing, gobyexample shows you how to do it properly. That's the "by example" part. The same applies to the make(map... example.

What I'm saying is that the accompanying comments don't have to explain the language / repeat the spec. The examples is what matter.

I don't object to improving the comment here slightly, it's just that your suggestion was (IMHO) less clear than the current text.

[amaddio]

@eliben sorry for my late reply.

How about this?

From:

"This function intSeq returns another function, which we define anonymously in the body of intSeq. The returned function closes over the variable i to form a closure."

To:

"This function intSeq returns an anonymous function which closes over the variable i to form a closure. The function signatures of the outer and the anonymous function must match."

[eliben]

This doesn't sound true; "function signature" = parameters + return values, and these don't necessarily have to match.

What you really want to say is something about the return type of the outer function being the type of the internal function

[amaddio]

You are absolutely right. The parameters are no constraint. What about this:

"This function intSeq returns an anonymous function which closes over the variable i to form a closure. The return type of the outer and the inner (anonymous) function must match."

[eliben]

Still not amazing, because of the ambiguity of "and". It reads like the return value of outer = return value of inner, whereas we want return value of outer = inner

[amaddio]

Gotcha. What about these two:

A

"This function intSeq returns an anonymous function which closes over the variable i to form a closure. The return type of the outer function must match the return type of the inner function."

B

"This function intSeq returns an anonymous function which closes over the variable i to form a closure. The return type of the outer function must be equal to the return type of the inner function."