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

[Michael Jones]

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  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  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.

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

[Uwe Dauernheim]

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  > 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.

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

[Jesse McNelis]

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.
>
> 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.

switch g := f.(type) {
case int, int8, int16, int32, int64, uint, uint8, uint16, uint32,
uint64, float32, float64:
   //g is of type interface{}
}

"the expression in the TypeSwitchGuard" is 'f' which is of type
interface{} in this case. Thus 'g' has the type interface{} within the
case.

The comparison 'g == 0'  is false because 'g' contains a float64 and 0
is an int.

-- 
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.

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

[Jan Mercl]

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 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+unsubscr...@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.

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

[Uwe Dauernheim]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.