Thanks for the quick reply, Ian. You're right, my simplified example doesn't make sense on its own. It's really about giving the WithTypeParameter more than one option in the type list, which allows that single function to accept func types with different numbers of type parameters, in a way that maintains static typing AND attaches useful methods to these func closures for dynamic checking later in the compilation sequence. This example (which requires us to spell out some types, since inference doesn't work) shows the sort of catch-all function I want to write: https://play.golang.com/p/MtKjQdV-RmP
Maybe there's a different reason why THIS wouldn't work :) Again, I /can/ just manually convert my func literals to the named Func0/Func1[T1]/Func2[T1, T2]/etc types, but since they all have type parameters it is really verbose, and better to have a func to intercept instead. E.g. this (https://play.golang.com/p/mlh9P6wNKEY) is essentially what I'm doing today; there is an extra call to WrapFunc0/WrapFunc1/etc for each builtin type. Boo! It's obviously not a big deal, but I also have some dreams of figuring out how to do vararg type parameters with whatever functionality we have today, and I believe this is one avenue to reduce what boilerplate may be required to do it. Or maybe that's just a pipe dream!) On Saturday, January 31, 2026 at 11:40:58 AM UTC-7 Ian Lance Taylor wrote: > On Sat, Jan 31, 2026 at 10:01 AM Kevin Chowski <[email protected]> wrote: > > > > Hi all, I read through the spec to look for the rules about this but I > think this is a consequence of a couple different parts, so I'm reaching > out here for some expert help. I'm also wondering if the current state of > affairs is due to a hard limitation or simply because "no one has found > time to work on it yet". > > > > Why doesn't type inference choose a named type when it is an obvious > candidate, and could it be enhanced to do so without too much trouble? What > I mean: https://play.golang.com/p/gWMOBr-rMgq > > > > (btw, if you're surprised to see `var myFunc MyFunc = f` works correctly > in that above link, it's because there are special assignment rules for > *some* unnamed types, but not all; to be clear, I understand none of these > work for MyInt and I (believe I) know why it's a good thing: > https://play.golang.com/p/iN0Tz5i480A) > > > > Staving off "why do you even want this?": I want to do (something like) > this because I have a lisp implementation where you can register typesafe > builtins from Go code, and I'm trying to emulate variable type parameters > so that instead of calling CompileFunc1 for functions with 1 argument, > CompileFunc2 for those with 2, etc, I can just use some CompileFuncN and > have the type inference magically sort out the right type for me :) So I do > already have a relatively simple way to handle this and don't need a new > workaround, but I want to understand why I can't do something else. > > This line: > > func WithTypeParameter[F MyFunc](f F) {} > > says that WithTypeParameter requires a type argument that matches > MyFunc. There is only such type argument, namely MyFunc itself. That > seems useless, so I don't understand your goal. We could probably add > an inference rule saying that if the type of the argument is > assignable to the type parameter constraint (when the constraint is > not an interface type), then use the type parameter constraint. But > approximately zero real programs would use that, because approximately > zero real programs would use a type parameter that only accepts a > single type argument. > > 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/b925d14a-e38c-4020-9cb1-689a924435can%40googlegroups.com.
