Currently (inside functions) if compiler sees something that can be a generic function call or something like that, it TRIES to parse it, if it fails, it will parse expression (or I don't remember whatever else).
To really know what exactly we need to parse, we either need a more specific syntax, or generate symbol table, which I really don't want to do. I don't know how to create symbol tables when you don't need function to be defined first to be called.
I'm leaning towards things like this ...
... for generic function definitions:
my_generic_function :: <T, U, V>(x: T, y: U, z: V) -> T { ... }
// Before there was this:
// my_generic_function<T, U, V> :: (x: T, y: U, z: V) -> T { ... }
... and for generic function calls (applies to generic namespaces too):
// I thought about this kind of syntax when I just started working on generics,
// but it seems like Walter Bright (the creator of D-lang) was already using this
// syntax before I was born
x := my_generic_function!s16,u64,f64(1h, 2ul, 32.4lf);
// It will help us to avoid trying to guess trying to parse something like that:
// *cast(*int)(my_generic_function<int>(1+2+3) + 123) = 123;
// ^ ^
// | May be a "greater than" operator
// May be a "less than" operator
// And what if instead of int there was 'x', just imagine:
//
// x := 5u; // We define 'x' to be a 'u32'
// y := funny_identifier<x>(1+2+3); // And now everything is messed up
// 'x' in this case may be a type, and 'funny_identifier' just a variable,
// but IT WILL BE parsed like a call to a generic function 'funny_identifier'
// with type 'x' passed as a generic type and an expression '1+2+3' as an argument.
// And it will fail at analysis. To make it work, we'll need to make 2 variants of it
// with an AST marked as a questionable one, which contains 2 AST variants of this.
// And then this "debate" should be resolved at semantic analysis stage, which will be
// a massive headache. I think it will be better to just change this syntax.
// That's it.
Currently (inside functions) if compiler sees something that can be a generic function call or something like that, it TRIES to parse it, if it fails, it will parse expression (or I don't remember whatever else).
To really know what exactly we need to parse, we either need a more specific syntax, or generate symbol table, which I really don't want to do. I don't know how to create symbol tables when you don't need function to be defined first to be called.
I'm leaning towards things like this ...
... for generic function definitions:
... and for generic function calls (applies to generic namespaces too):