On Sun, Jul 3, 2016 at 11:57 PM, Gordon Klaus wrote:
> Ok, so strictly speaking there is no bug. Both gc and gccgo are
> spec-compliant; gc just opts not to raise an error in this case. (One might
> say it is a bug that gc doesn't raise the error consistently, but I don't
> think the spec says a
Ok, so strictly speaking there is no bug. Both gc and gccgo are
spec-compliant; gc just opts not to raise an error in this case. (One
might say it is a bug that gc doesn't raise the error consistently, but I
don't think the spec says anything about consistency, only optionality.)
In any case, I
On Sat, Jul 2, 2016 at 2:20 AM, wrote:
> More generally, this is https://github.com/golang/go/issues/10989.
>
> Such ineffectual assignments can be detected using
> https://github.com/gordonklaus/ineffassign.
>
> An analysis showed that only a small fraction of such were bugs, making the
> backwa
More generally, this is https://github.com/golang/go/issues/10989.
Such ineffectual assignments can be detected
using https://github.com/gordonklaus/ineffassign.
An analysis showed that only a small fraction of such were bugs, making the
backwards-incompatible language change not worthwhile.
@
On Sat, Jun 25, 2016 at 12:34 PM, Val wrote:
> Hello
> It seems that this code doesn't compile :
>
> func main() {
> var err error
> err = f()
> }
>
> prog.go:8: err declared and not used
>
>
> but this one does :
>
> func main() {
> var err error
> g := func() {
> err = f(
