Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

This is mentioned directly in the language specification under For statements with range clause : For each entry it assigns iteration values to corresponding iteration > variables if present and then executes the block. and > For an array, pointer to arra

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

Hmm, well I can't give better reasoning off the top of my head, but I still have to wonder why you expect the behavior of those constructs to be the same, particularly. Imagine, you would like to capture both the iteration variable and the value itself, for example: var i, v = 0, "" for i, v = ran

Re: [go-nuts] Check for minimum Go version

You might want to follow the discussion in golang.org/issue/21207 which might be related to this, depending on the reason you need to know the minimum Go version. `go version` doesn't return the version number on non-tagged releases so if you're building off of tip, for example, the output is a bit

Re: [go-nuts] labeled loop vs for statement inlining

I can't explain exactly because my explanation is likely very flawed, but the logic you are looking for is in https://github.com/golang/go/blob/320ddcf8344beb1c322f3a7f0a251eea5e442a10/src/cmd/compile/internal/gc/inl.go#L186. Basically, labeled loops are not considered "hairy" by the compiler and c

Re: [go-nuts] What is the difference between fmt.Print and rand.Intn functions here?

You can use something like `go build -gcflags="-m -m" ...` to get more information about why something escape. David Chase has added excellent descriptions of why something escapes. There's a lot of detail about fmt.Print functions escape, in general, but without going into detail, we can look at

Re: [go-nuts] Go beginner asks for code review

On Thu, Sep 22, 2016 at 3:31 PM, Leandro Motta Barros wrote: > Hi Sam, > > Looks like your response got truncated. :-/ > > Anyway, there is a good deal of nice tips, there. I am updating my code to > take your feedback into account. Thanks a lot! > > There is one point I still wondering about, ho

Re: [go-nuts] Re: go escape analysis

In the first example, make does not escape the scope of the for statement. In the second example, make is assigned to m, which is outside of the scope of the for statement, which means the make operation escapes its scope and subsequently, is heap allocated. If you want more information about why s

Re: [go-nuts] Re: go escape analysis

You're correct. I'm sorry about my first response; it was too brief and led to the confusion you have. The Go escape analysis algorithm has a concept of "loopdepth" (shortened as ld in debug output). The loopdepth is -1 for global variables, 0 for input arguments to a function, 1 for the top level

Re: [go-nuts] Re: go escape analysis

Hmm, I'm not so sure if that's the rule. The rules are expressed in the code in https://github.com/golang/go/blob/master/src/cmd/ compile/internal/gc/esc.go, which is unlikely to make any significant changes in the near future. Those rules aren't written in plain english, but we should not discoura

Re: [go-nuts] go closure escape analysis

In example1, the // BAD: y escapes is there because y should not escape from that function, but the current algorithm needs to be improved for this case. In that closure, the address of y is captured as the closure argument p and since p is only dereferenced, the analysis should not consider it to

Re: [go-nuts] go closure escape analysis

Sorry, poor explanation again. When a variable is used from outside a closure's scope, it is *captured* by the closure. Usually that means that the closure function is modified to include a reference to that variable when it is called as a regular function. An example from the compiler: https://gi

Re: [go-nuts] go closure escape analysis

To see the escape analysis results, compile with -gcflags "-m -m -m -m". The code in each of the example should be relatively similar, which is why it is a bug that one of them causes the variable to escape to the heap. On Wed, Oct 5, 2016 at 4:46 PM, 刘桂祥 wrote: > 1: In example2_modified.go (y

Re: [go-nuts] don't understand the comment in spec Type assertions section

In that example y is a nil interface value of type l. The last line implies that for a type assertion to another interface type, the operation will only be possible if the underlying value implements both interfaces. That is, the value must have an m() method as well as all of io.reader methods or

Re: [go-nuts] Wrong order for float64 conversion

In the Go Language specification under operators ( https://golang.org/ref/spec#Operators), there are a couple examples that demonstrate this exact situation: var u2 = 1< wrote: > https://play.golang.org/p/iZTogUaWWl > > In the program above, foo and bar compile but baz does not. It fails with >

Re: [go-nuts] Should go vet catch people attempting to identify errors by inspecting err.Error()?

+joetsai, who has been thinking about this a lot recently On Thu, Oct 20, 2016 at 11:10 AM, Pietro Gagliardi wrote: > It seems that something about the way the error interface is designed is > not intuitive enough for some, because a number of people on the IRC > channel keep coming up asking wh

Re: [go-nuts] Re: Looking for Golang counterpart to 'params' in Python

That error seems to be from writing that expression outside of a function. There's no problem with structs supporting string fields: https://play.golang.org/p/YeP2qhRdxp. On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg wrote: > Do structs support strings? I tried this: > > type Params st

Re: [go-nuts] Re: Looking for Golang counterpart to 'params' in Python

I see, well that makes the compiler error make more sense. You're trying to declare a function type within a function. Use a function literal instead, for example: `doIT := func(p Params) string { ... }`. On Tue, Dec 13, 2016 at 11:18 AM, Betsy Lichtenberg wrote: > The expression is inside of th

Re: [go-nuts] Documenting Interfaces

It seems like you would need to do both, at least eventually. I'm not sure why you're saying that you will end up copy-pasting the comments; it seems like each implementation would have something particular about it that would change the documentation. For example, io.Reader must be documented at t

Re: [go-nuts] fmt.Printf("%v") panics where %#v doesn't

In your example, MyError2 does not have an Error() method so it is not called. From the fmt package docs (golang.org/pkg/fmt): - 3. If the %v verb is used with the # flag (%#v) and the operand implements the GoStringer interface, that will be invoked. - If the format (which is implicitly

Re: [go-nuts] Returning an interface using a concrete type?

Seems to work fine to me: https://play.golang.org/p/6DmDKQLrzd. In your snippet, the concrete type doesn't implement the interface, however. What was the error you got when trying to do apply this to more complicated code. Chris On Tue, Feb 14, 2017 at 12:01 PM, Aaron Wood wrote: > I'm wonderi

Re: [go-nuts] Naming projects with multiple words

There's definitely no idiom here. Do what the octokittens do and probably use the first or second option, in that order. The third seems awkward, unless the underscore has some specific meaning (like how _unix is used to compile architecture-specific code). And I'm not really sure if the capitaliza