I don't understand where we are talking past each other. I am aware, what the current behavior is. I am (and T L was asking) for technical reasons why a) any justification for the behavior of the type-assertion doesn't apply to map-access and b) any justification for the behavior of the map-access doesn't apply to type-assertions? I don't believe there is any.
On Thu, Sep 29, 2016 at 11:48 AM, Dave Cheney <d...@cheney.net> wrote: > 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. > Why is that a show-stopper for v := iface.(someType) but not for v := someMap[k] The value will be of type someType either way, it will be just as valid a value in both cases and the consequences of assuming it's non-zero are just as dire in both cases. You could argue that assuming that a key is present in a map is just as broken an assumption as assuming that an interface value contains a value of a given type. You could argue that just as v, _ := someMap[k] v := someMap[k] are equivalent, v, _ := iface.(someType) v := iface.(someType) should be equivalent. Or, you could also argue, if you prefer, that just as v := iface.(someType) should panic because you shan't just assume that iface contains a someType and continue working with a possibly invalid value, so should v := someMap[k] panic, because you shan't just assume that a map contains a given key and continue working with a possibly invalid value. You could argue, that requiring v, _ := iface.(someType) for the non-panicy behavior is better, because it makes explicit that you've thought about it and are aware that iface could possibly be something else, but just as well could you argue that v, _ := someMap[k] for the non-panicy behavior is better for exactly the same reasons. Again, I'm not really saying it's a *bad* thing that there is an inconsistency here, but I also don't think that it can really be argued that there is much of a technical reason for these two, on the surface very similar constructs, to behave this differently. I believe the true answer is "for historical reasons. No one realized this, when converging on the ,ok construct". Which I think would be a fine answer. -- 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.
