Re: [go-nuts] Unexpected type switch case listing & equality behaviour for float64

This is the Go designers trying to be helpful...the value of generic element is made as specific as possible in the guarded clause. Maybe this part of the spec should be clarified: "note...when multiple types...the least general applicable type." On Fri, Dec 30, 2016 at 9:09 AM, Uwe Dauernheim

Re: [go-nuts] Unexpected type switch case listing & equality behaviour for float64

Apologies for not being more specific with a distilled exampled, the reason is that I don't understand if this is a bug or expected. Agreed I should have left the first lines out. I think Michael Jones summarised it quite well: > I think the problem is the unexpected type of g. In the "spread

Re: [go-nuts] Unexpected type switch case listing & equality behaviour for float64

On Sat, Dec 31, 2016 at 3:26 AM, Uwe Dauernheim wrote: > It seem a float64 of value 0.0 as types interface{} can't be compared equal > to 0 in an exhaustive case clause type list, but can be compared equal in > almost any other scenario. > >

Re: [go-nuts] Unexpected type switch case listing & equality behaviour for float64

Can you please reduce the example to a single failing case and state what's the expected outcome instead? I, for one, fail to spot where the perceived problem is (when reading it on the phone). On Fri, Dec 30, 2016, 17:26 Uwe Dauernheim wrote: > It seem a float64 of value

[go-nuts] Unexpected type switch case listing & equality behaviour for float64

It seem a float64 of value 0.0 as types interface{} can't be compared equal to 0 in an exhaustive case clause type list, but can be compared equal in almost any other scenario. https://play.golang.org/p/t2u2GGp565 I find this unexpected. Could someone explain how case clause type lists in