Namespace for modules

[certik]

So you can require module data to be referenced like module.var:

use, namespace :: utils
...
call utils%savetxt()

One issue with just use utils is that it still pollutes your local namespace with savetxt, so that's the reason for use, namespace :: utils.

Other alternatives for syntax: use utils, only (or perhaps use utils, only:). Another alternative is use namespace utils (suggested by Milan Curcic). Or perhaps use, namespace :: utils, to by compatible with the existing syntax like use, intrinsic :: iso_fortran_env.

Initially proposed by Michael Zingale and further discussed at Twitter.

[certik]

The paper is submitted at https://j3-fortran.org/doc/year/19/19-246.txt. I will try to get feedback on it from the committee. CC @zingale.

[cmacmackin]

Agree, this seems like a good feature.

[certik]

So the committee unfortunately did not consider this proposal at the meeting last week. I was hoping to get at least a general "yes" or "no" direction from the committee. But I talked to a few members directly, and I did not hear any "this is a bad idea", or "this should not be done".

Here is my plan:

1. Write a high quality full proposal for this. This means more use cases, we have to brainstorm any possible issues, and some members of the committee like to structure any new features as "requirements", "specification" and "syntax", so we should incorporate all that.

2. I will ask on the j3 mailinglist once a more complete proposal is ready to get some feedback

3. I will ensure that this gets to the committee program for next meeting to be officially considered for the 202y standard.

[certik]

@septcolor that's a valid concern. My plan to overcome this is to use this github repository to get support for proposals. If the Fortran community puts thumbs up for a proposal, or otherwise expresses strong interest, then relatively to other ideas proposed here it will be obvious which proposals are high priority, and which are low priority. And then it will be easier to argue for a particular proposal at the committee.

[FortranFan]

Fyi a new thread at comp.lang.fortran inquiring of a missing feature in current Fortran which can be met by the proposal here:
https://groups.google.com/d/msg/comp.lang.fortran/nYdFG0PCTWo/rjjLlAteDgAJ

By the way, I had a similar interest along the lines of this proposal several years ago:
https://groups.google.com/forum/#!msg/comp.lang.fortran/sNNnQaoqC9I/JFAEgsbeAPMJ

[certik]

Thanks @FortranFan. This is one of the popular issues in here and I am going to insist for the committee to consider it at the next meeting. However, I welcome any help with improving the current proposal (linked above).

[FortranFan]

@certik wrote:

..However, I welcome any help with improving the current proposal (linked above).

@certik and others interested in this, if you haven't already please take a note of comments online, especially by Ian Harvey at comp.lang.fortran such as this one:

Look at the last 3 questions in that comment: addressing these questions suitably will strengthen the proposal. Some aspects that come to my mind with these questions include:

1. USE statements can include unnamed operators (+,-*,/, etc.), assignment(=), etc. What is the impact of this proposal on their semantics?
2. What about named entities which are operators in USE statements e.g., operator(.cross_product.)? Does x .cross_product. y become x foo::operator(.cross_product.) y a la C++?
3. What about generic interfaces and their extension via USE statements?
4. Current standard has scoping unit semantics with MODULE subroutines/functions (e.g., for use in SUBMODULEs), INTERFACEs. BLOCK constructs, etc. that can be impacted by USE statements. What happens with them?