public static bool foo { // ...}if( foo string ){ // ...}A declaration that says 'this argument must be a type, and is referenced by identifier T'. Right now only single argument methods work, but eventually you'll be able to use type parameters as elements of a phrase declaration. I anticipate key uses being type operations like is/as, factory interfaces, and serialization sort of things.
Generic parameters to methods unfortunately has run into a snag. A snag I've run into 1-2 times before, so it's noteworthy enough to post as a warning to others. Plus, it helps me to think by writing about the problem.
Currently, generics are being implemented via a generic parameter which lives on a type, and a generic reference which lives... where-ever a type can go. When a type parameter is bound to a generic type, the generic parameter moves from the unbound list to a bound list (along side the type that is bound there) and a new type is returned with all the references replaced with the concrete type.
For generic methods where the type is inferred, the references serve as 'holes' for the inference to take place. The generic method (or type in certain cases) is overlaid on the concrete type. What you see through the holes is what is used for the generic parameters. To do that programmatically, the inference method starts at a point and walks along each method looking for the generic references. If there's a reference for the method it's inferring for, it looks at the concrete type and adds that to what it sees for that reference.
Once it's done, it binds what it finds to the parameters referenced. So:
foo( arg);foo(new string); // T = string;generic(T) foo(List arg);foo(new List); // T = int;foo( arg1, arg2);foo(new string, new int); // T = intersect(string,int) // // (since it sees multiple sources, it generates // the greatest common base class for them)And all that works nicely when I hardcode stuff with the infrastructure. I'm just adding syntax at this point.
The problem that has come up more than once now is in 'If there's a reference for the method it's inferring for'. Mechanically, that means if the generic parameter in the reference is in a list of targets passed through the inference method. The list is made from the generic parameters on the method, and the references exist in the method definitions for the signature. What happens is that they don't quite match. All of the data is the same; the name, the type-class, the generic type that owns the parameter... but not the references themselves.
So the inference fails, and the cause is somewhere I didn't reuse the generic parameter when making references. And of course they're all over the place since most everything uses generics for something. I could make the parameters into value types, but I did that with the types themselves and that turned out to be less useful than I anticipated (with its own set of problems). Mostly it's a matter of me doing debugging around this fragile construct. Bleh.
[edit: and not 15 minutes later I find the problem. I was being lazy and calling a factory twice rather than once and assigning the result in two places. So generics now work in declarations for 'normal' void foo( a, b, c){} sorta things. You can't actually use them yet since the name resolution ignores them... baby steps.]
