To summarise points of apparent consensus so far:
- we do not want to accept any new F77 code
- replacing F77 with a modern implementation is welcome, particularly if it is actively maintained
- There has been a huge effort to translate existing F77 code, mostly to C, and that has been worthwhile
The main point of disagreement is:
- for new algorithms, should we accept any Fortran at all, even if it is actively maintained modern Fortran?
Arguments against accepting it:
- it works against the goal of “no Fortran in SciPy”, an idea which was explored in Releasing (or not) 32-bit Windows wheels. This is compelling because of the build challenges which Fortran brings, and the lack of maintainers for existing Fortran in SciPy. (EDIT: see also the next comment)
- actively maintained code can always become unmaintained in the future. At that point the responsibility would fall to SciPy to maintain or translate it. So there is risk involved.
- Some new modern Fortran implementations are not mature and we should be careful to not start depending on projects in the “honeymoon phase”
Arguments for accepting it:
- it can be the easiest (sometimes perhaps the only reasonable) path to exposing new algorithm implementations to the wider Python community (ENH: optimize.minimize: Expose LINCOA, BOBYQA, NEWUOA, and UOBYQA · Issue #21554 · scipy/scipy · GitHub)
- we have managed to fight against the build challenges so far (The 'eu' in eucatastrophe – Why SciPy builds for Python 3.12 on Windows are a minor miracle | Labs) and feasibly(?) can continue to do so, with the development of (new) Flang
- we are still going to have Fortran for the foreseeable future (BLAS/LAPACK) (or not? Rewrite LAPACK so it's not in F77 · Issue #7 · scientific-python/faster-scientific-python-ideas · GitHub) so adding some more now doesn’t affect us on the build-side for the foreseeable also
- perhaps (good) automatic translation will become possible in the future with LFortran
- there is similar risk involved with code we vendor or depend on written in other languages. For some codebases, the risk (re: maintainability) with Fortran code can actually be not significantly worse than code like Boost.Math and SuperLU.
I don’t really have any opinions of my own to throw into the conversation yet, but perhaps others can expand on these points below.