On Saturday, January 6, 2024 at 7:58:55 AM UTC-5 Axel Wagner wrote: I took this idea into account in my original message. It is bullet point 2. The case against this is that it would likely make type-checking Go code (co-)NP-complete. If you watch my talk about methods in union elements <https://www.youtube.com/watch?v=0w4Px-yR8D8> (or read the supplemental blog post about it <https://blog.merovius.de/posts/2024-01-05_constraining_complexity/>), you'll see that I have to spend a bit of work on constructing a negation to prove (co-)NP-completeness. If we just put in a negation operator, that work would no longer even be necessary and the proof becomes trivial. In fact, C++ concepts *have* a plain negation operator in their constraint language and are known to be NP-complete to type-check.
One of the things I have really appreciated about the Go language — and a main reason I was drawn to it — was how the Go team has been pragmatic in the past instead of allowing conceptual purity to block functionality that would be useful in service of software engineering. Specifically to your argument about negation and NP-completeness, yes in the general case unrestrained negation could result in NP-completeness. However, a better and more pragmatic approach would be to restrain negation to those things that can be performed efficiently. Alternately the Go team could recast the solution as something other than negation; e.g. an *"exception" *as in *"allow `any` type, excepting those types that conflict with type `Y`." * For the case of type embedding, the methods of *`**Y**`* are known at compile time and the type methods can be compared as efficiently with the type parameter as checking methods of an interface parameter. That is unless there is some other unintended consequences I am not seeing and you have not mentioned. -Mike P.S. Ironically, ensuring the benefits of embedded type parameters are *"too small"* is itself a class of NP problem. -- 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/5f4208fe-730b-41cb-bd55-62f7d9bdbb58n%40googlegroups.com.
