Proposals from Amir Shahmoradi

[certik]

@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.

@certik Ondrej, I am not sure where my requests for enhancements should go on the J3 repository. So I am going to list it here and hopefully you will know much better or help realize where I should submit them:

1. Coarray slicing (equivalent of MPI_gather)

   real :: co_Vector[*]
   real, allocatable :: LocalVector(:)
   ...
   LocalVector = co_Vector[ 1 : num_images() ]
   ...

   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:

   integer :: i
   real :: co_Vector[*]
   real, allocatable :: LocalVector(:)
   ...
   allocate( LocalVector(1 : num_images()) )
   do i = 1, num_images()
       LocalVector(i) = co_Vector[i]
   end do
   ...

2. the ability to use dummy optional arguments when not present in a procedure:

   function runSampler(chainSize)
       integer, intent(in), optional :: chainSize
       if (.not.present(chainSize)) chainSize = 10000
       ...

   This is similar to the RFE by Curcic et al, so I won't explain it further here.

3. 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.

4. 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.

[certik]

@shahmoradi, here are my comments:

1. Can you create a new issue just for this? I don't think that's been proposed yet.

2. I think that might be a duplicate of Allow setting default value for optional dummy argument #22. If so, please make sure you voice your support there and add a thumbs up for it.

3. I think that might be a duplicate of The preprocessor should be standardized #65. If so, please make sure you voice your support there and add a thumbs up for it.

4. Thank you for our support. Some relevant issues are: Proposal for general-use templates #29, Templates for functions/subroutines #4, Traits For Types #125 and many others. @tclune is officially leading an effort to make progress on this.

[milancurcic]

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.

[certik]

Let's discuss item 1. in its dedicated issue.

[shahmoradi]

@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.

[certik]

@shahmoradi yes, please create a new issue for coarray slicing.