-
Notifications
You must be signed in to change notification settings - Fork 11
Description
As of PR #229, the Caffeine implementations of *_with_team_number only accept team_number == -1 (the initial team) and team_number == prif_team_number() (the number of the current team). These are exactly the valid inputs that can be implemented scalably and efficiently.
What's missing is support for team_number == n where n specifies the team number for a sibling team of the current team. Sibling team number access is a fundamentally non-scalable Fortran language feature, and IMHO represents a design mistake in Fortran. The most straightforward algorithms for implementing sibling team number support would impose a significant time and memory scalability burden on the common case of FORM_TEAM, even in programs that never utilize sibling team number support. I find this tradeoff to be unacceptable.
I may eventually deploy a non-scalable algorithm to support sibling team numbers (probably only when the user explicitly enables sibling team number support via environment variable), but only if I can be convinced the design doesn't unduly penalize scalability for the majority of programs that wisely avoid this obscure and misguided feature.