[J3] [SC22WG5.6397] Request for deletion of "US 21, part 1. Enumeration types" from Fortran 202X

[Van Snyder]

On Sat, 2022-06-11 at 19:02 -0400, Vipul Parekh via J3 wrote:
> Dear Representatives of National Body Members of WG5,
> 
> Please consider directing J3 to delete the edits associated with the
> feature labeled "US 21, part 1. Enumeration types" [1] from the
> Committee Draft revision 22-007r2 and also the eventual submission
> with ISO and IEC toward the official publication corresponding to
> Fortran 202X.
> 
> Not only does the semantics associated with said "Enumeration Types"
> feature fall short of meeting several of the crucial use cases for
> this facility, the current design also makes it impossible, nearly if
> not entirely, to extend this feature satisfactorily in a future
> revision of the standard.  Of particular concern is the consideration
> of each enumerator name in the definition of an enumeration type as a
> Class(1) identifier.
> 
> Please provide guidance as to the avenue and form for a formal
> petition should that be seen as necessary for consideration of this
> request.
> 
> Most Sincerely,
> Vipul S. Parekh
> parekhvs at gmail.com
> 
> [1] ISO/IEC JTC1/SC22/WG5 N2194, "The new features of Fortran 202x",
> John Reid, March 21, 2022

I don't think it's necessary or useful to delete Enumeration Types. I
also don't like that enumerators are class-one names. But that
requirement can be changed in the future without invalidating any
programs that conform to the requirements as presently written.

One avenue of future extension is an additional class of names,
consisting of enumerators. The rules could be something like "If
enumerators of different enumeration types, having the same identifier,
appear in the same scoping unit, they shall not appear except as
arguments to the constructors of their respective types."

This doesn't solve the problem of defining two types in the same
module, having enumerators with the same names, and then trying to
access an enumerator of only one of the types by USE association. But
that problem is a minor problem, and can be solved in many situations
by defining the types in different modules.

The alternative, which would indeed require to remove the feature and
re-design it, would be to require enumerators always to be qualified by
their type names, probably using percent-sign notation. That is an ugly
solution.

Ada does not have this problem with enumerators. It considers
enumerators to be zero-argument constant generic functions. A processor
works out the type of an enumerator by applying its usual generic
resolution ruiles, which take function result types into consideration.
This has worked since before the first Ada standard. Fortran committees
have resisted adding function result types to generic resolution rules,
even though that part of the generic resolution problem was solved more
than forty years ago. If Fortran's generic resolution rules were to be
augmented to take function result types into consideration, it would
not be necessary to qualify an enumerator with its type name, either
always or only when enumerators of different types, having the same
identifier, appear within the same scoping unit. Other problems would
be solved at the same time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220611/06c791b5/attachment-0001.htm>