3 ms·

And I agree with the proposal committee for declining your request. For a language that prides in having great backward compatibility, what you were proposing w

• rkangel 6y ago
  The author did say "Back when we thought "Go 2" was going to have lots of breaking changes". It seems reasonable in that light.
  • gwd 6y ago
    Exactly; if we're going to "rip the bandaid off", just do it all at once. The idea seemed in line with other aspects of golang: for instance, you can't compare an int32 and an int64 directly -- the compiler will throw a warning if you don't cast the int32 to int64 before comparing. This is obviously because, as old-school C programmers, they recognized that automatic promotion is a trap that caused all kinds of issues. I'd argue that the "nil interface is not nil" trap is quite a bit worse. As it turns out, a lot of the improvements they were thinking about could be done without breaking backwards compatibility; which of course has some huge advantages.