> 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.
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.
But I understand that's not the point, the point is not about the syntax,
rather it's about behaviors.
I pretty strongly believe that anything that improves the ability of the
programmer to be more clear about the nature of the program and their
intentions is definite win. I think there's a lot of cost to the lack of
clarity in programs, and I think if we can improve that we should. But I
also think I'm just repeating myself on that point, I've said as much in my
earlier comments.
Given that, let's think about the idea that "type of t would be an
interface type that implements Test[T] for an arbitrary T".
This makes sense to me: I *should* be able to write your slice example. If
I have a function "func Pop(s Slice) Slice { return s[1:] }".
The fact that I can't feels surprising; although I've gotten used to it and
I know I can't do that, if I were newly introduced to Go and ran across
this I would find it confusing.
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.
So there's a fairly obvious benefit: the language more closely aligns with
expectations, and is thus easier to learn and understand. (And it is easier
to communicate intent)
The compiler can catch some errors that it couldn't before.
I now have access to the properties of T within my function without needing
to specify a precise type
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.
The type system and language become more complicated in a literal sense, in
that they have more components that can interact.
Like earlier, I think the literal sense misses the point; from a user
perspective they are less complicated, because their behavior better aligns
with expectations.
-JM
P.S. Appreciate the conversation. I really do feel I need to think more
about the implications of introducing the rule that generic types would be
interface types implementing T for all of T.
On Thursday, August 7, 2025 at 1:51:59 PM UTC-7 Ian Lance Taylor wrote:
> On Thu, Aug 7, 2025 at 12:25 PM John Wilkinson <[email protected]>
> wrote:
> >
> > > The only goal here seems to be to use types to better communicate what
> a function can accept
> >
> > Isn't that an improvement? That feels aligned with Go's objectives.
>
> Among Go's objectives is that the language be simple and easy to learn
> and understand. The current type system is very simple. 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?" But if we do make it work, the type system and the language
> become more complicated.
>
> > The idea that is a step towards writing types rather than code is
> impossible to quantify; the same could be said of type aliases or generics.
>
> I don't agree. Both type aliases and generics were driven by a lack of
> power in the language: "there is code that we can't write today, and
> adding these features will make it possible to write that code". I
> don't see a similar argument for your proposal.
>
> Every language change is a cost/benefit decision. All language
> proposals have benefits; if they didn't have benefits, nobody would
> propose them. All language proposals have costs. Are the costs worth
> the benefits?
>
> 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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/ad6b3907-27f9-4a7b-9eaf-2b2058a658d6n%40googlegroups.com.
