Proposals for February 24 - 28, 2020 J3 committee meeting

[certik]

Here are the submitted documents: https://j3-fortran.org/doc/meeting/221.

Let's use this issue to help coordinate and prioritize proposals for the next J3 meeting 221 in February 24-28, 2020.

Everybody, can you please ensure you put thumbs up on issues that you find high priority, and then help us create high quality proposals for this meeting by submitting PRs against this repository. Once a proposal is ready in this repository, I am happy to submit it officially so that it appears at https://j3-fortran.org/doc/meeting/221.

What do you think should be the top 3 to 5 issues that we should concentrate on? Go ahead and comment below with your personal top 3 to 5 issues. Let's see if we can agree on some of those as a community. Then let's ensure we have good proposals for those. Beyond those, if you feel strongly about some feature, go ahead and start drafting a proposal and motivate in there why it is a good feature.

[certik]

Here is the current list of issues sorted by the number of thumbs up, which we can use as an (imperfect) hint of which issues might be popular.

[klausler]

I suggest that the proposals can be triaged into three tiers: (1) fixes to actual bugs in the language, (2) features that enable new usages that are impossible or impractical today, and (3) conveniences.

[certik]

I'll go first. Here is my list (I will update it and/or re-order if I get convinced based on a discussion):

1. Standard library proposals #104

2. Consider releasing Fortran standard every 3 years instead of 5 #36

3. Allow modules to be nested like in Python #86

4. Namespace for modules #1

5. Matrix literals #102

Comments: Number 1. might not need a formal proposal, but it's something I want to informally discuss with every committee member and try to get their support. For me this is the highest priority, and actually something we can achieve as a community today, with today's compilers. This would be a huge quality of life improvement and big productivity boost for any Fortran developer. The number 2. also is more of an issue to get support at the committee for. The numbers 3., 4. and 5. would require proposals.

I will also try to write proposals for #81, and #40. Especially #40 would be a nice quality of life improvement.

[certik]

@klausler great idea, I made this a new issue #123, so that we can discuss the details and make that happen.

[certik]

@FortranFan, @milancurcic, @jacobwilliams, @jvdp1, @zjibben, @marshallward, @zbeekman, @everythingfunctional, @qolin1, @rweed, @gronki, @ivan-pi, @aradi, @arjenmarkus, @cmacmackin, @Beliavsky, @pbrady

The next J3 meeting is less than 2 months away. We brainstormed a lot of ideas, but now it's time to turn some of the ideas into action and create a few high quality proposals. Please comment here with your top five priorities for this next meeting. Hopefully there will be some overlap, and then let's work on the issues/proposals of common interest.

(I tried to tag everybody who created issues here, feel free to forward this issue to others.)

[FortranFan]

@certik wrote:

..
The next J3 meeting is less than 2 months away. We brainstormed a lot of ideas, but now it's time to turn some of the ideas into action and create a few high quality proposals. Please comment here with your top five priorities for this next meeting. Hopefully there will be some overlap, and then let's work on the issues/proposals of common interest.
..

@certik , thank you very much for your initiative.

My concern is the posted agenda for the meeting (https://j3-fortran.org/doc/year/20/agenda221.txt) that appears essentially a carbon copy of the last N number of meetings and which effectively only allocates time ("officially at least") for Fortran 202X items.

But now, not only is the work-list for Fortran 202X fixed to that set by the Tokyo meeting last summer as noted at this link https://isotc.iso.org/livelink/livelink?func=ll&objId=20646091&objAction=Open, but even the feature specifications also appear locked in place based on discussion and votes at the Tokyo meeting.

There seems to be no room to maneuver on any 202X items even e.g., with US-21 on "typed enums" vis-a-vis #46 (comment) and #46 (comment) other than to wait for years when the next window of opportunity opens up for any improvements to features implemented in an earlier revision.

How do you see any proposal fit into this scheme? Thanks,

[certik]

@FortranFan thanks for sharing the concerns. As @sblionel mentioned in #98 (comment), the committee will consider every proposal submitted to it. His word is good enough for me. As you know, it will take some time and iterations and several committee reviews for every new proposal / idea that we submit in order to get in. So let's get started. Once we have proposals that have been positively reviewed by the committee, and are rock solid, and backed by the community, then let's convince the committee to put it into the standard sooner than in 10 years (i.e., to fix #36). But we need those proposals first, so let's work on that, and once they are ready or near ready, let's have a discussion at the committee how to fix #36.

[jvdp1]

Here is my list:

1. Templates for functions/subroutines #4
2. Protected attribute for variables in derived types #16
3. Consider releasing Fortran standard every 3 years instead of 5 #36
4. Namespace for modules #1
5. Matrix literals #102

I could also add #22 and #104

[cmacmackin]

My votes:

1. Templates for functions/subroutines #4 (or one of the other similar issues)
2. Remove restrictions on proc-component-ref #27 (although this was recently rejected by the committee, without good reason in my view)
3. Namespace for modules #1
4. Allow derived type components to have target attribute #28
5. Overloading () #119

Personally I'd like to see #30 taken forward, but not too many people agreed with me that this was important. Obviously #36 would also be very helpful.

[rweed]

My list would be:
#1 - recently encountered a case where this would be useful
#4/29 - anything that gets us closer to better generics even if its not what everyone wants
#61 - my proposal so I have to support it. I think its of immediate use and would be trivial for the developers to implement so it might have a chance of gaining traction with the committee
#65 - if we can't have intrinsic generics/templates a standardized pre-processor that makes generating different versions of the same code easier is the next best thing
#70 - a standard assert routine would be very useful as a first step to better error handleing. Also something that looks like it would be straight forward to implement.
#40/90 - I would at least like some language in the standard that encourages developers to make explicit typeing the default mode and force people who want to stick with implicit typing use a compiler flag (opposite to the current mode in many compilers) to make it the default. Again, I see this as more of a policy problem than a technical one. It just takes a vendor/developer to summon the courage to change the default mode.

I also support the items currently on the J3 F202y list (ie coroutines etc.)

[everythingfunctional]

1. Templates for functions/subroutines #4
2. Traits For Types #125
3. Remove restrictions on proc-component-ref #27 - Combined with Templates for functions/subroutines #4 and Traits For Types #125, this would make Fortran's capabilities on par with practically every other language. Even if some techniques or patterns would be cumbersome without some additional work, they would at least be possible.
4. Protected attribute for variables in derived types #16 - I would use this tomorrow. I've exposed some attributes as public explicitly for performance reasons, and this would make that safer.
5. Consider releasing Fortran standard every 3 years instead of 5 #36 - 5 years is absolutely too long to wait between releases