Thank you Milan. I sent a Calendar invite to everybody who responded to the poll. Anybody is invited to join (even if you didn’t respond to the poll).
We can use this thread to note down what we want to discuss.
I plan to create a comparison of examples in Go (the proposal there), C++, Rust and a preliminary syntax for Fortran. And at the video call use these to discuss the alternatives that we have on the table and pros / cons of each.
I would like to mainly concentrate on the general template mechanism (plus concepts) for this phone call. After we have a good path forward on this, we should later also discuss how the templates play with multidimensional arrays (the current discussion at the J3 mailinglist) and at https://github.com/j3-fortran/fortran_proposals/issues/185.
Thank you everybody who attended, we had I believe 10 participants. Here is a summary:
The above 3 areas are good, the last bullet point should be generalized to other corner cases and “warts” in Fortran, although the rank agnostic arrays is definitely one of the main ones
We should prototype the Fortran pseudocode for the second bullet point above using the abstract class in Fortran and we need to answer exactly how the templates+concepts differ from the abstract class: templates are strictly compile time and allow an effective multiple inheritance.
For the second bullet point should be extended with multiple templates / constraints to see how it looks like
We need to figure out how parametrized modules Fortran proposal fits into this, whether it is one possible implementation of the “strong concept” idea, or something else.
We should find a better terminology for templates + strong concepts. Such as type parameters and constraints/traits.
Rust requires to explicitly specify that a user type is satisfying a trait, Go does not. We seemed to agree we should go the Go route, which seems to be natural for users. The reason Rust does it is so that you can append more methods to a class outside where it is defined, but in Fortran (as in Go I believe), you define everything at one place, so it seems more natural to satisfy the traint/concept/constraint implicitly.
We should make progress on the above 3 areas as much as we can. As we make further progress, the effort will serve as a “prototype” that allows people to have a concrete idea about how the generics could be done and allows them to reason about the various proposal. From there we need to then write down use cases and requirements for generics. And then there will be multiple proposals how they could be implemented, using the ideas from our “prototype” (or other ideas).
As we make progress, we need to think how to get the whole J3 committee up to speed with the “strong concept” and other ideas, and convince them this is a good “requirement” that the compiler checks both the library code and a user code. And other ideas that we figure out in the Generics subgroup.
we need to answer exactly how the templates+concepts differ from the abstract class
Though just a naive reaction, I guess the abstract-class approach cannot necessarily be used when the program is coming from third-party libraries (assuming that the source code cannot be modified freely).