On Friday, September 30, 2016 at 3:12:54 AM UTC+8, Ian Lance Taylor wrote: > > On Thu, Sep 29, 2016 at 12:08 AM, T L <tapi...@gmail.com <javascript:>> > 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 >
Ian, great explanation for this question! On the other hand, Konstantin Khomoutov's explanation really shows the consideration when go team made the syntax decision. -- 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.
