@rwmsu LFortran has support for high performance lists, sets, dicts as part of the compiler itself (needed and used by LPython), although it’s not exposed yet in the LFortran frontend. That’s a whole different discussion what the best syntax should be for that.
@FortranFan the big issue that we’ll need to tackle in generics is this: currently the design is procedure based. You currently can’t call methods on the template T (although the design can be extended to allow that). I actually think the current design can be a great fit for Fortran, since many (but not all!) Fortran codes are written in a procedural style. However, the procedural style generics require you to pass all the “procedures” as part of the parameter list. For example in the above, you can see generic_sum{integer, operator(+), cast_integer}(a_i), where we need to pass all the operations explicitly, in this case the “+” operation and the integer casting operation. The compiler of course will be able to infer many of these automatically, but the question is if the overall experience is good enough. It’s not clear! We can’t now from a whiteboard. We need to implement it and start using it and see if the syntax and semantics can be simplified enough to be nicely ergonomic. The answer might very well be it can’t. In that case, we need to do class based generics, see below.
What the full generics syntax allows is to only specify this (long) parameter list once, so it becomes a lot easier if you have a lot of functions, all of which accept almost the same parameter list. So you can think of it in an “inverted” way: the main syntax is the simple generics, but once you have a lot of functions, you might want to use the “full” syntax, which actually becomes simpler in that case.
Now: the design can be extended to support classes (when I say “class”, I mean derived type with type bound procedures). In this design, you would call methods on the class inside your generic code, so then you don’t need to expose all operations via parameter list. This greatly simplifies usage and instantiation. The class operations can be defined with an “interface” block, and this whole thing can be done in a way that merges the various “traits” proposals floating around here. These class based generics have downsides too, it’s not as simple to compose different generic codes together, it’s in some ways limiting what you can do with it as a user, since you are required to always provide a user class type with the prescribed methods. The current procedure based generics are more flexible in this regard.
Hopefully the above shows the main issue that we still need to tackle. And why we need to tackle it right now, not wait 3 years, as this requires a prototype and many iterations of the design. However, I don’t see any complete blocker, we just need to get a usable procedure based generics out there as quickly as we can, those will always be useful. And then if the ergonomic can’t be made nice enough, we need to also design and implement the class based generics.