On Thu, Aug 7, 2025 at 10:46 AM John Wilkinson <john.wilkin...@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/CAOyqgcUPP3ENx9UDbd-Vbe6ypefsp1C0itGeU6d8M%3DE9jACa2g%40mail.gmail.com.
