I think the two examples you give would be great. It would be really nice
to be able to rely on known properties of a given Test[T].
But, I don't feel like I understand the implications of allowing that. I
think understand those implications would be useful, and a good discussion
to have. I'm certainly up for that.
On the other hand, I don't see any negative implications for allowing
"Slice" or "Test" if they then must be type asserted before they can be
used.
I like the code-first, functionality-first approach of Go. But I also think
clarity is important, and I think Go values clarity very highly.
Very practically, this proposal is just pointing out that "interface{} says
nothing", and that's not great, and we could do better in this circumstance.
And I realize that I'm not in as good a position as you to comment on what
Go is about, but my experience has been that Go eschews "power" in favor of
clarity.
> 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.
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 think the idea that writing types is a priori bad is wrong. Writing types
in the service of nothing useful is bad, but writing types to clarify
proper usage is really helpful.
Although I agree (I think- assuming you are more in favor of this) that
making it so "t would be an interface type that implements Test[T] for an
arbitrary T" would be preferable.
----
-JM
On Thursday, August 7, 2025 at 11:05:09 AM UTC-7 Ian Lance Taylor wrote:
> On Thu, Aug 7, 2025 at 10:46 AM John Wilkinson <john.wi...@rocky.edu>
> wrote:
> >
> > Proposal
> >
> > If the compiler allowed the use of uninstantiated types as function
> parameters, the programmer could better communicate the expectations of the
> function to the caller.
> >
> > func Print(t Test) { switch t := t.(type) { case Test[string]:
> fmt.Println(t.Get()) default: fmt.Println("not a supported type") } }
>
> In effect, in Go terms, the type of t would be an interface type that
> implements Test[T] for an arbitrary T.
>
> Let's suppose I write
>
> type Slice[T] []T
>
> Can I then write
>
> func Pop(s Slice) Slice { return s[1:] }
>
> ?
>
> Going back to the original example, can I write
>
> func Print(t Test) {
> if g, ok := t.(interface { Get[string] }; ok {
> fmt.Println(g.Get())
> }
> }
>
> ? That is, am I truly restricted to a type assertion to Test[T] for
> some T, or can I rely on other properties of Test[T]?
>
>
> In general, Go prefers that people write executable code, rather than
> designing types. This is different from other languages, which often
> suggest that you first design your types, then write your code. In Go
> interface types can emerge from code, rather than the other way
> around.
>
> This proposal doesn't make the language more powerful. As you say, you
> can already do everything using the type "any". The only goal here
> seems to be to use types to better communicate what a function can
> accept. As such this seems like a step toward writing types rather
> than writing code. It doesn't seem like a good fit for Go.
>
> 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/4e85e7ae-556b-4c81-8ec8-28277c9acdafn%40googlegroups.com.
