That's what happens now with the two arg version, the one arg version panics rather than letting you think you got a valid value of the type you expected.
On Thu, 29 Sep 2016, 19:44 Axel Wagner <axel.wagner...@googlemail.com> wrote: > The thing you are asserting to, obviously? The types are not a problem if > you do > v, ok := iface.(someType) > v simply has type someType and will be the zero-value if iface doesn't > contain a someType. Why should this be a problem for the non-comma-ok > version? > I.e., what would be the technical difficulty in making > v := iface.(someType) > semantically equivalent to > v, _ := iface.(someType) > 'cause I don't see any. > > On Thu, Sep 29, 2016 at 11:40 AM, Dave Cheney <d...@cheney.net> wrote: > >> A type assertion is dangerous because if the thing you are asserting to >> doesn't match the type of the value inside the interface, what type should >> the result be? With the map example the type of the result is known. >> >> On Thu, 29 Sep 2016, 19:36 Axel Wagner <axel.wagner...@googlemail.com> >> wrote: >> >>> On Thu, Sep 29, 2016 at 9:31 AM, Dave Cheney <d...@cheney.net> wrote: >>> >>>> Sorry, I misspoke, this logic does not apply to map lookup >>> >>> >>> But why? It seems to me, everything you said can just as easily be >>> applied to map lookups. Why is a zero-value on a type-assertion potentially >>> dangerous, while it's fine on a map-lookup? >>> I don't see anything in your E-Mail that is specific to type-assertions >>> (I mean. It's specific to type-assertions as implemented. Just not as >>> theorized). >>> >>> Indeed, you could argue that, as we deal just fine with the behavior for >>> maps, we would probably deal just fine with the behavior for type >>> assertions. And that the same conveniences we get from *not* panic'ing on >>> map-accesses also would apply to type-assertions. >>> >>> So… I have to agree, that there is an inconsistency here. I don't think >>> it's a *bad* thing and I prefer my type-assertions panic'ing and my >>> map-accesses not-panic'ing, but I would be hard pressed to give a technical >>> argument why they should be different. >>> >> > -- 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.
