Thanks for considering my weird idea, Ian. I thought I had a way around what you describe but after working a little on it I couldn't get anything to work. One observation was that I could use a type alias with a throwaway type (e.g. `type Func0_Wrapper[T any] = Func0`) to strip a type parameter off, but you're right that I couldn't convince the compiler to decide a type for me for this. I also thought I could do some trickiness with some extra methods, to convince the compiler to pick some trivial type for Func0 cases, but alas I ran out of options relatively quickly. Back to idly toying with the idea in my brain for now.
On Saturday, January 31, 2026 at 3:48:51 PM UTC-7 Ian Lance Taylor wrote: > On Sat, Jan 31, 2026 at 12:35 PM Kevin Chowski <[email protected]> wrote: > > > > 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!) > > I see. I don't see how to make this work. In particular the compiler > is going to want to infer the Func1 argument type, but if you are > using Func0 then there is no such type. > > 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/d0040454-e2c7-4530-8700-9872e8864dc9n%40googlegroups.com.
