On Thu, Sep 29, 2016 at 12:08 AM, T L <tapir....@gmail.com> wrote: > > On Thursday, September 29, 2016 at 1:31:41 PM UTC+8, Ian Lance Taylor wrote: >> >> On Wed, Sep 28, 2016 at 10:02 PM, T L <tapi...@gmail.com> 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 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. >> >> Why do you think there is an inconsistency? >> >> Let me put it another way. A type assertion and a map index are two >> different kinds of expressions. They do different things. What kind >> of consistency do you expect between them? > > > I just feel that It is weird that the behavior of type assertion depends on > whether the second OK result variable is provided or not.
This conversation has reminded me that early in the development of the language map lookups worked like type assertions: if you wrote m[k], and k was not present in the map, then you got a run-time panic. In other words, exactly like when writing v.(T), if v is not of type T, you get a run-time panic. For both cases, the comma-ok statement let you check whether the result succeeded without having the panic. So, back then, the two statements did not have the inconsistency that concerns you. The behavior for maps changed with https://codereview.appspot.com/673042. The discussion that led to the change was https://groups.google.com/forum/#!msg/golang-nuts/2VQ7h0CMkjg/2qE3rFSfo_4J . So, OK, from a certain perspective, there is an inconsistency. And the reason there is an inconsistency is that it made Go programming easier to not have maps panic. But I think type assertion are a very different matter. I don't think anybody wants to write a Go program that has a type assertion that silently fails. The only possible argument for that being a good idea would be to avoid something that looks like it might be an inconsistency. That is, in my opinion, a terrible argument. Ian -- 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.
