> On Aug 8, 2025, at 5:35 PM, Ian Lance Taylor <i...@golang.org> wrote: > A generic type without type arguments is an abstract type that doesn't, in > fact by definition can't, exist at run time. I don't think many people expect > to be able to use an abstract type.
Speaking for myself — I may not have *expected* it, but I was certainly disappointed to learn it was not possible. > You can write the same code today using the "any" type. This new feature adds > additional compiler type checking. It prevents you from writing certain kinds > of code, by detecting that that code is erroneous. It doesn't permit you to > write anything that you can't write today. One of the main reasons I moved to Go from dynamic languages was the compiler’s ability to catch breakage during refactor. Every time I must fall back to `any` and a type assertion, I lose that robustness guarantee. So while it is technically true that we can already write the same code with `any`, the real issue is that doing so reduces type safety. This proposal is not about “clearer communication”, it is about preserving robustness. >> Both type aliases and generics were justified by the fact that “there is >> code we can’t write today, and adding this feature will make it possible.” >> I’d argue this is the same: there is code we *can’t write robustly* today, >> and adding this feature would make that possible. > > I can get the `i`th element of a slice, so it’s surprising I can’t do the > same with my defined type if it’s generic and uninstantiated. Do others find that surprising? Here is one data point: I do. Regarding complexity: I don’t find the “complexity in the language” argument compelling here. Supporting this would make the language *easier* to use for most people. For the majority, this would just work as expected; no need to understand the complexity of *why* it doesn’t. The minority who do understand the edge cases are already capable of handling that complexity. In other words, the cost in learnability is low, while the gain is useful type safety. The only case where I’d agree complexity is a real problem is if it caused measurable compiler slowdowns or made the compiler significantly harder to maintain. But you have said compiler complexity is a minor cost here, so I assume that’s not the case. -Mike #jmtcw -- 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 visit https://groups.google.com/d/msgid/golang-nuts/617AA4A7-FF60-4D30-8320-0E3425B98675%40newclarity.net.
