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 <u...@dauernheim.net> wrote:
> 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 out"
> switch clauses it is int/float/... but in the "all as one" case it is still
> a generic interface.
>
> And Jesse McNelis gave the answer I believe. I misread the specs,
> specifically I confused the SimpleStmt with the TypeSwitchGuard.
>
> I am aware that I comparisons here have to be done thoughtful, but the
> behaviour between the different styles of switch cases is what felt
> unexpected.
>
> On Friday, December 30, 2016 at 5:48:57 PM UTC+1, Jan Mercl wrote:
>>
>> 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 <u...@dauernheim.net> 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.
>>>
>>> https://play.golang.org/p/t2u2GGp565
>>>
>>> I find this unexpected. Could someone explain how case clause type lists
>>> in type assertions work?
>>>
>>> The language specification states:
>>>
>>> > In clauses with a case listing exactly one type, the variable has that
>>> type; otherwise, the variable has the type of the expression in the
>>> TypeSwitchGuard.
>>>
>>> In the provided playground is no TypeSwitchGuard given, so this rule
>>> should not affect behaviour.
>>>
>>>
>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> -j
>>
> --
> 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, visit https://groups.google.com/d/optout.
>
--
Michael T. Jones
michael.jo...@gmail.com
--
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, visit https://groups.google.com/d/optout.
