[go-nuts] API fixes for sync.Mutex and friends?

Some Go types like sync.Mutex have a subtle API issue, where the objects really shouldn't be copied or passed around into different function calls, e.g. to a goroutine worker. However, this is not enforced by the current API, but merely mentioned in the documentation, which is easily ignored. I

Re: [go-nuts] Check if a file is executable

Er, the expression mode & 0111 evaluates whether a file mode is executable by authorized users. mode | 0111 would always yield a file mode with all executable bits enabled. On Tuesday, June 12, 2012 at 4:52:27 PM UTC-5, Kyle Lemons wrote: > > From http://golang.org/pkg/os/#FileMode > "The nine l

[go-nuts] infinite loop in gotpl

Enjoy, yall! https://play.golang.org/p/SgUnPeiQgE 🐹🤙 -- 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. For more options,

[go-nuts] Perl die("") equivalent for Go?

For command line applications, it's often useful to terminate with a one-line string message, without presenting a stack trace. Could Go get a die-like standard function for this? panic() and log.Panic() are similar to die, except that panic always shows a trace, even when a very newbie-facing

[go-nuts] Clearer float parsing API

Could we separate ParseFloat() into distinct signatures for the corresponding float widths? Parsing a 32-bit float shouldn't be returned as a 64-bit float :/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and sto

[go-nuts] Possible to generate BIOS binaries?

Can Go code target BIOS environments, or perhaps Go assembler target BIOS? Which GOOS, GOARCH settings should be used? -- 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 emai

[go-nuts] Re: Trying to understand := and named return values

Seems like named returns + if/for/switch initializers = a shadowing nightmare. I wish the Go compiler emitted a loud warning on shadowing, as this is a dangerously subtle problem out there. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To uns