To: J3 J3/18-123 From: Tom Clune Subject: Distilled issues for container use case Date: 2018-February-13 Reference: 18-110r1 The use-case paper for containers (18-110r1) is a bit rambling. This paper omits the justification and list of use cases, and summarizes the various aspects of developing containers that could be improved through new language Features. 1) Generic programming Generic programming would significantly reduce the development effort for containers for varying types of contained entities. If something akin to C++ standard templates were used, then some mechanism for template _specialization_ would also be required for important corner cases. In particular, enabling containers of deferred length strings would likely require judicious use of some sort of specialization. 2) Accessors Succinct notation for getting/setting elements of containers would be very beneficial. Fortran arrays allow expressions such as: A(i,j) = 5 and it would be desirable with a container V to do something like V(k) = 5 3) Improved semantics for iterators Exploiting Fortran's existing loop construct (DO WHILE ... END DO) can be made to work adequately for simple cases with an explicit call to the iterator incrementor at the end of the loop. But if the user ever uses CYCLE, it is all too easy to forget to include an explicit increment there as well which can lead to subtle/confusing problems. It is desirable to have a mechanism that guarantees the increment happens for each iteration. Note that such a feature/generalization has potential applications beyond just containers. 4) Containers of entities with POINTER attribute Fortran does not provide a mechanism to robustly order entities with the POINTER attribute. This prevents any implementation of containers of such entities that rely on such ordering. While Vectors of such entities are implementable, Sets are not, nor are Maps with keys that have the pointer attribute. `