On Thu, Aug 7, 2025 at 5:02 PM John Wilkinson <john.wilkin...@rocky.edu> wrote: > > > A change like this makes it more complicated, leading to questions like the > > ones I posed earlier: "it seems logical that this should work, so why > > doesn't it work?" > > Isn't this the situation today? It seems logical I could use the > uninstantiated type in a function definition (and for the compiler to > restrict calls to just to implementers of the type), but it doesn't work. > It is not obvious to me that the language becomes more complicated. The > current approach (passing "any") would remain possible, but it would be > clearer to be more specific and use the actual required type, so that would > likely be preferred.
Perhaps, but personally I don't see it. 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. > I appreciate your explanation of lack of power in the language re type > aliases and generics. > From a completely literal standpoint, this proposal qualifies: there is code > I cannot write today, and adding this feature would make it possible. I don't think that's correct, except in a pedantic sense. 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. > A big part of being easy to learn and understand is aligning with user > expectations. > Obviously, this can't be done perfectly 100% of the time, but in general use > builds a mental model of a thing, and then deviations of that mental model > are a large part of making something hard to learn and difficult to > understand. > My mental model of a slice starts out as, "I have a slice and I can get > elements from it." > My mental model of type definitions says "Anything I can do with the > underlying, I can do with my defined type)". > I can get the "i" element of a slice, therefore, I should be able to get the > "i" element of my type. > But I can't, because it's generic and uninstantiated and I cannot even pass > the type into the function. > This is surprising. I would be curious to know whether anybody else finds it surprising (and posting here on golang-nuts is a good way to ask). I have not encountered this myself. > The cost is more complexity in the compiler. I don't think there would be a > significant performance hit to compilation time, but I have no data to back > that up. To be clear, compiler complexity is a minor cost here. The cost is complexity in the language. We need to define a new kind of abstract type, define what operations are permitted on it, and so forth. Ian -- 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/CAOyqgcUEkGSBxtCg-HMFyioEgcFXz17HQgoy1f%2B8EGgUzhnqqQ%40mail.gmail.com.
