[go-nuts] Why can't you take the address of a function's return value?

tion hard-coded by the compatibility guarantee? Conrad -- 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.c

[go-nuts] SQL Interceptor

<https://github.com/grpc-ecosystem/go-grpc-middleware>. AFAICT this would keep full backwards compatibility. Wdyt? Is that a patch that would be acceptable and generally useful? Conrad -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] SQL Interceptor

On Mon, 2018-09-10 at 09:44 +0200, Jan Mercl wrote: > > On Mon, Sep 10, 2018 at 8:16 AM Conrad Wood > wrote: > > > Wdyt? Is that a patch that would be acceptable and generally > useful? > > It could be tried and evaluated first as an external package. > > -- 

Re: [go-nuts] SQL Interceptor

On Mon, 2018-09-10 at 09:05 +0100, Tristan Colgate wrote: > There are two existing projects used to achieve similar goals: > > https://github.com/ExpansiveWorlds/instrumentedsql > https://github.com/gchaincl/sqlhooks > > native support could probably improve things a little, but this is a > very

Re: [go-nuts] SQL Interceptor

's not obvious what > that would look like for SQL, or if that is even desirable. >   There is a pre-existing db/sql issue to discuss tracing (which > would also facilitate metrics collection): > https://github.com/golang/go/issues/18080 > > > On Mon, 10 Sep 2018 at 09:22

[go-nuts] repeatable builds

server would execute the same steps and produce the binaries required and use the same dependencies as the compiler on the developer workstation. How do others set this up with Go? Thanks, Conrad -- You received this message because you are subscribed to the Google Groups "golang-nuts&qu

Re: [go-nuts] repeatable builds

017 13:42, "Conrad Wood" wrote: > > Hi, > > > > We're considering Go for new services in our software architecture. > > Generally it seems like a good fit. There are a few things I'm not > > sure about though, so I wonder what others do: > > >

Re: [go-nuts] repeatable builds

Hi, Thanks for that. Right now, checking in an entire GOPATH makes the most sense to me. That seems to eliminate the need for godep, hellogopher etc... altogether. presumably, when you update the packages, you just use -u flag for "go get", right? Conrad On Wednesday, 18 October

[go-nuts] Re: Why can't you take the address of a function's return value?

On Mon, Aug 29, 2016 at 10:17 AM, wrote:On Friday, 26 August 2016 23:58:53 UTC-4, T L wrote:And there is also an exception for the counter rule: map elements are not addressable.Just because you can use the assignment syntax m[k]=v to update a map element does not mean a map e

[go-nuts] Confusing type rules

rule, which is only if []S is assignable to []T) Conrad -- 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. F

[go-nuts] Re: Confusing type rules

Thanks both! On Saturday, June 3, 2017 at 5:22:20 PM UTC-7, Xio Fen wrote: > > To answer the first point - the keyword is "*assignable*" here - an slice > []int{1,23} is not assignable to a slice []I where I is a type of int. See > https://golang.org/ref/spec#Assignability > > ( also golang tre