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

Re: [go-nuts] runtime.GOOS case

You can see how the different runtime.GOOS values are defined in the OS-specific runtime files like https://github.com/golang/go/blob/master/src/runtime/internal/sys/zgoos_windows.go. They happen to be lowercase, but I don't know anything that guarantees that in any future. Curious though, why

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

at after iteration. I'm not sure if that's official reasoning, but the semantics of range statements are different in many other situations as well so it seems consistent to me. On Tue, Jul 25, 2017 at 4:11 PM, Axel Wagner <axel.wagner...@googlemail.com> wrote: > On Wed, Jul 26, 2017

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

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

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

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

auth string > } > > func doIt(p Params) string { > return p.auth > } > > doIt(Params{auth: }) > > res, _ := http.DefaultClient.Do(req) > > defer res.Body.Close() > body, _ := ioutil.ReadAll(res.Body)

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:

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

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] 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] go closure escape analysis

t; wrote: > 1: In example2_modified.go (y=x line should be *y=x ?) and that is the > same as example1.go ??? >but in example1.go y is escapted and example2.go is not. > 2:how do I see the compile handle closure call results ? compile para ? > > 在 2016年10月5日星期三 UTC+8下午11:3

Re: [go-nuts] go closure escape analysis

will pass pointer to the > closure func so I doubt in example2.go y is passed to closure > > I don't know the compile how to analysis this and decide that can be > allocated in stack correctly ? > > 在 2016年10月4日星期二 UTC+8下午11:54:02，Chris Manghane写道： >> >> In example1, t

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

t; > { > m = make(map[int]int) > } > > _ = m > } > > if I do this m will not escape just want to know what's the scope rule for > escape ? puzzled > <http://www.baidu.com/link?url=ApC817U9uUoCFHhS_dqb5JzUWJQsslUUA6_TDv3LDZBJgaA-G2ZbRfWA-2cGajgU_MHmTiXVEouM

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

Re: [go-nuts] wired value

A simple example: https://play.golang.org/p/RNgW-Ya5BS Conversions between numeric types : "For the conversion of non-constant numeric values, the following rules apply: 1. When converting between integer types, if the value is a signed integer, it

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