-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposals from Amir Shahmoradi #174
Comments
@shahmoradi, here are my comments:
|
I'd like to see item 1 as well and it could be a candidate for stdlib or standalone library. Why wait for it to be standardized? Let's make it. |
Let's discuss item 1. in its dedicated issue. |
@certik Thanks Ondrej. So should I create a new issue for coarray slicing then? (or is there already one?) I think the other items are well discussed in the issues you mentioned. |
@shahmoradi yes, please create a new issue for coarray slicing. |
@shahmoradi posted the following issues at #162, but I am moving them here. Let's create individual issues out of those, or add the comments there to already existing issues.
Coarray slicing (equivalent of MPI_gather)
As far as I am aware, coarray slicing is currently not supported in Fortran 2018. This feature, however, is highly desired for writing a more concise code and potentially enabling more compiler optimization. The equivalent standard-conforming code would be:
the ability to use dummy optional arguments when not present in a procedure:
This is similar to the RFE by Curcic et al, so I won't explain it further here.
standardized support for a minimal healthy subset of the C/Fortran preprocessing features. preprocessors are essential for writing scalable code and many compilers are fully or partially support some level of preprocessing. C has this as part of the language. Adding preprocessors to Fortran would ensure that the community's use of preprocessors is more disciplined and supported by the language standard.
further support for template metaprogramming. I know that this is already a highly popular RFE. So I just suffice to mention my strong support for it.
The text was updated successfully, but these errors were encountered: