Because they are different operations, they just happen to share a similar syntax.
For example a, b := 1, 0 c := a - b d := a / b One of these generates no result, the other panics. Following your logic, should division have a two arg form that says if the dividend was zero, and if so would that require all arithmetic operations to support this syntax? I don't know the historical reason why those two arg forms are like they are, they were there when I got here, and at a time there was a push to add more two arg forms, for division especially, but that didn't pan out. There is an inconsistency here, but only if you want to assume that maps and interface assertions are the same operation because they share the same syntax. > On 29 Sep. 2016, at 20:05, Axel Wagner <axel.wagner...@googlemail.com> wrote: > > 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.
