Since @pure prevents foo from accessing global/static variables, since it can only call other @pure functions, and since its only parameters are themselves other types, then the return type of V must solely depend on the *types* T and U (and what can be gotten from T & U using @pure functions). While this is not the same thing as “known at compile time”, it does (I think) guarantee that V can be deduced only using what is known about T and U *at compile time*. If the return value of such a function could used as a “proper” type (i.e., it could be used like “var bar: foo(Int.self, String.self)”, for instance), it wouldn’t so much remove the “types must be known at compile time” restriction, as it would give the programmer a powerful way to tell the compiler *how* to figure out what the type is.

The use case I’m thinking of is admittedly pretty narrow… I personally want this feature to help with a work-around I’m using for Swift not having non-type generic parameters:

Again, I realize the use case I’ve presented is pretty narrow (and one that’ll hopefully become a moot point later), but it seems like this would be a *very* expressive way to expand the power of generic types.

Anyway… Yay? Nay? Implementation-wise, my first thought is to embed the REPL in the generic specialization system then use the function in question as its input to extend the generic specialization system, but I don’t know if that’s the right place to handle it, let alone if that’s a feasible idea.