The type set is defined as "all types which implement the interface".
Any type implementing interface{int; m()} has to both1. have the method m() 2. be the type int That's not possible. Therefore, the type set of that interface is empty. The problem is, that the type set is potentially hard to calculate. I wrote a proof of that at some point: https://github.com/golang/go/issues/45346#issuecomment-813639125 However, since then, the design has changed and become more restricted, so the proof might no longer be accurate (I also wrote a follow-up, but the design has changed after that as well). So, I don't know if this is still NP-hard. If it is, though, that would present a problem, because if the spec defines interface types to be identical, if their type sets are identical, the compiler would have to solve an NP-hard problem to check if two interface types are indeed identical. Obviously, we want to avoid needing a compiler to do that, so our definition should then not depend on the actual type sets. Currently, this isn't a problem, because the compiler only has to check if two interface types are identical, when this is trivial to do, by comparing method sets. So, in a sense, it doesn't matter if "the spec is right or not", because there is no one disagreeing with the spec. But we might want to consider this, if we ever allow *other* interfaces to be full types (i.e. to take values), because then the compiler would have to actually be able to check that. At that point, we should either a) be certain that we can efficiently compute type sets, or b) change the definition to no longer rely on type sets (as we did for e.g. whether or not it's valid to call methods or use operators). On Thu, Mar 24, 2022 at 2:03 PM Jan Mercl <0xj...@gmail.com> wrote: > On Thu, Mar 24, 2022 at 1:56 PM 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > > I believe you are correct in that the spec needs work here. The two > should probably not be considered identical, but they are according to the > spec right now. > > I'm not sure this poses an immediate problem, as I don't think such > interfaces can ever appear in a position where type identity matters. > > I think the specs are correct, type set != method set. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGdua%3DPeCideS1kLtpwrz8GZTVNL1zm_2m_mogCmx%3DzDQ%40mail.gmail.com.
