(true(),false()) select bool() == Ambiguous - True:True(true(),false()) select false() == false() - True:True(true(),false()) select true() == true() - True:True(true(),false()) select null() == Undefinded - True:True(true(),void(true)) select true() == true() - True:True(true(),void(true)) select void(null) == void(true) - True:TrueMy little toy language is coming along. Tonight's work? Starting in on method groups. The few little unit tests from above are checking on the function that does type picking/resolution (rather than the actual dispatch). As you might be able to see, it will be smart enough to pick the right one based on return type if the requested return type sufficiently limits the options.
For now at least. I suspect that I might run into troubles/conflicts when actually getting the dispatch going. Once this gets done I should be able to start importing basic/test .NET types. Once that is done, I can start on the really dubious stuff (making the syntax analysis smart enough to allow user defined operators).
An interesting side effect of how I did things allows this sort of thing to work:
delegate int foo(int x, int y);foo IntOperator = delegate(){return(42);};You'll still need to call IntOperator with 2 ints, but the assignment will work and you'll always get 42 back. I'm not sure if this has some advantage or if it'll prevent useful error reporting later on. Kinda weird, but for now it's in.
