To: J3 J3/23-147 From: Malcolm Cohen Subject: Recommendation of DATA items for F202y Date: 2023-February-23 Reference: 22-182, 22-176r5. 0. Introduction All proposals should be considered to start with minus 100 points. Even if an individual item seems small, there is an issue with language bloat (just look how long it is taking gfortran/flang/ some-other-compilers to implement even F2003!). Cost-benefit analysis is thus essential. 1. Recommended items for consideration 3. Namespace for modules The proposals here are multitudinous; much of the functionality is already provided by existing syntax, the main thing that looks useful would be a syntax for "remote access" to module entities, e.g. "modulename % entityname". Not sure % is the best thing for this, but would avoid introducing a new operator like back-quote or hash e.g. "modulename ` entityname" or "modulename # entityname". Probably don't need to use any "namespace" keyword, just do the remote access. If this worked despite an "ONLY" clause that would be useful, but possibly confusing. 4. More assumed-rank functionality The github proposals are not overly inspiring, but subgroup agrees that more could be done to make assumed-rank more useful inside of Fortran. Rank-agnostic subscripting may play a part here. Perhaps SUM/PRODUCT should be usable with assumed-rank, similarly SELECT TYPE. Also see 23-130 for another idea here. 5. Obsolete (not delete) default implicit typing This cannot feasibly be deleted (compilers will need to support it for the foreseeable future), but it has been disrecommended by many for years, so seems reasonable to require a compiler to be able to diagnose (with a warning) use of implicit typing without an explicit IMPLICIT statement. was 6 in 176r4. Pointer intent Subgroup agrees that some form of read-only pointers is desirable. Some work has already been done on this. The simplest reasonable solution should be sought. 9. Enable Polymorphic Outputs from Pure This bears further investigation to establish the scope. Is it just the final procedures, or is there more about type-bound procedures? Perhaps one possibility is a PURE attribute on a type? Should that require pure type-bound generics as well as pure finals? (probably not). Worth investigating, but might have quite limited applicability. 14. "Proper" enumeration types Subgroup agrees that additional functionality for our existing enumeration types would be a good idea. There is a clear path to using our existing types in a "scoped" fashion. Care needs to be taken to avoid an overly-complicated facility. Scoped access to enumerators, if done, should use the same mechanism as remote access to module entities (item 3 above) if that is done. Keeping this simple would keep the desirability high, getting overly complicated would make it less desirable as well as a lot more work. 16. Program-specified default KINDs for constants and intrinsics. There have been proposals in the past, which foundered because it was thought too hard to do in the time available. We agree that something like this would be used if it were available and simple enough. 2. Undecided items 11. Default values for absent arguments Doing something here does not seem very hard, but they also do not seem terribly useful in general (though there are some good uses, those look to be fairly rare). Conditional arguments already handle some of these in a reasonable way. 3. Disrecommended items - do not proceed 1. Delete default implicit typing Undesirable, Unacceptable. Doing this would drive away existing customers. Those who need this know how to type -u. 2. Delete implied SAVE for initialized variables "use the assignment statement, Luke" Undesirable, low usefulness. Silent change of semantics is unacceptable. 7. bf16 and fp16 Fortran has had the ability to access a processor-provided bf16 or fp16 since 1991. And IEEE support thereof since F2018. No additional support is required. 8. Somehow fix the issue of mixed precision Silent change of semantics would be unacceptable. Undesirable. Difficult. 9. Augmented assignment This has been suggested before, and been found to be controversial and/or not as useful as envisaged. Low bang-for-buck. Does not work with defined assignment/operators. Does not work for division. Possible to make it work, but complications. 11. Revisit strings There may be value in re-examining the issues, but many proposals in the past tended to suggest intrinsics for what would be very simple expressions already. F2023 already added more intrinsics. We are not closing the door to concrete suggestions: they will definitely be considered. 13. Simple functions in constant expressions Low desirability. Large scope. Difficult. 14. Non-extensible extensible derived type We even have a keyword already that we could use for this. But does not seem useful enough for the complication. 16. Review all the restrictions on polymorphic entities and remove as many as is reasonable. It is impossible to guess the scope without more information on what the proposer has in mind. We awaited with bated breath, but nothing more was forthcoming. ===END===