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/CAOyqgcWSVCQtRgXop5W7qT-Rn-_BNSx4dWF71UfFmJRtz0NW5w%40mail.gmail.com.
