On Thursday, September 29, 2016 at 1:33:40 PM UTC+8, Micky wrote: > > TL, the simplest reason is this: > > You can live without the "ok idiom" when retrieving a map value but you > cannot when type asserting. Think of the consequences for rest of your > program, if you forgot to check the status of assertion that is failed (but > you didn't know) because the compiler didn't panic! It would be a travesty. > > For compiler's perspective, see Andrey's response. >
But I don't check the status of an assertion and the the status is false, I surely expect to get a zero value of the wrong type in the assertion. > > On Thu, Sep 29, 2016 at 10:06 AM, Henrik Johansson <dahan...@gmail.com > <javascript:>> wrote: > >> I am not sure but perhaps as simple as it is a very natural and known >> behavior of maps and to make it work syntactically as the type assertion >> would make it weird. >> >> On Thu, Sep 29, 2016, 07:02 T L <tapi...@gmail.com <javascript:>> wrote: >> >>> >>> >>> On Thursday, September 29, 2016 at 12:56:57 PM UTC+8, Micky wrote: >>>> >>>> The reason is directly stated in the Go language spec: >>>> >>>> "If the type assertion holds, the value of the expression is the value >>>> stored in x and its type is T. If the type assertion is false, a run-time >>>> panic <https://golang.org/ref/spec#Run_time_panics> occurs." >>>> >>>> Here "hold" means if it succeeds. >>>> >>>> >>> I know of the syntax in spec. >>> I just want to understand what is the deep reason for the syntax >>> inconsistency between map index and type assert. >>> >>> >>>> >>>> On Thu, Sep 29, 2016 at 9:53 AM, T L <tapi...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Thursday, September 29, 2016 at 12:32:48 PM UTC+8, Henrik Johansson >>>>> wrote: >>>>>> >>>>>> This is just how type assertion works. >>>>>> If you don't use the dual return it panics if the actual type is >>>>>> different from the one you try to assert. >>>>>> >>>>> >>>>> but what is the underlining reason for the inconsistency between map >>>>> index and type assert? >>>>> >>>>> >>>>>> >>>>>> On Thu, Sep 29, 2016, 05:26 T L <tapi...@gmail.com> wrote: >>>>>> >>>>>>> package main >>>>>>> >>>>>>> func main() { >>>>>>> var m = map[string]int{} >>>>>>> _, _ = m["abc"] // ok >>>>>>> _ = m["abc"] // ok >>>>>>> >>>>>>> var i interface{} = 789 >>>>>>> _, _ = i.(bool) // ok >>>>>>> _ = i.(bool) // panic: interface conversion: interface is int, >>>>>>> not bool >>>>>>> } >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>>> >>>>>> -- >>>>> 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. >>>>> >>>> >>>> -- >>> 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 <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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 <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
