Skip to content

Prepare default value for optional arguments proposal for submission. #145

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

Merged
merged 3 commits into from
Feb 21, 2020

Conversation

zjibben
Copy link
Member

@zjibben zjibben commented Feb 21, 2020

This continues the default-value saga from #22 #137 and #140.

I made a few formatting changes, added an introduction, and tried to capture some of the discussion in #140 about intent(out) arguments. My goal is to make sure our interests and the possible different behaviors are expressed, so the Committee has some ideas to consider. I'd like to get it in shape to submit before the meeting next week, and hope to discuss it there.

@jvdp1, I added your name to the proposal if you don't mind. Please let me know if you would like this changed and if spelling is correct.

Copy link
Contributor

@jvdp1 jvdp1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this PR. I added a few minor comments and use case (it might not be the most appropriate?).
Also, I missed the scenario intent(inout).

Comment on lines +170 to +172
A third option is that optional intent(out) variables with a specified
default are always initialized to that default, even when present,
rather than leaving them undefined.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am in favor of such a behavior. However, what would the behavior be for:

subroutine foo(a)
  real, intent(out), allocatable, optional :: a(:, :) = 0
end subroutine foo

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a very good question, and I think applies to intent(in) and intent(inout) arguments too (if no actual argument is given). I’ll add a section 5.3 on allocatable arrays, it definitely should be addressed. Off the top of my head, one option is of course to forbid defaults for allocatables. This isn’t preferable, but I suspect allowing defaults for scalars only would still address the majority of use cases. Another is to forbid array broadcasting as a default specifier. This would mean a(:) = [0,0] would be permissible, but not a(:) = 0. Any other ideas?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is indeed also true for intent(in) and intent(inout). I have no knowlegde about compiler development, so I have no idea what would be possible to implement or not. The easiest thing is probably to forbid default values for allocatable arrays, but it could complicate the standard.


A third option is that optional intent(out) variables with a specified
default are always initialized to that default, even when present,
rather than leaving them undefined.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The scenario intent(inout) (or no specification of intent()) is missing. Its behavior would probably depend on the behaviors of intent(in) and intent(out), e.g., as proposed by @everythingfunctional (which might not be in agreement with all different proposed options for intent(out)):

"If it is intent(inout) and the caller provides an actual argument, it wil get the value of the actual argument, AND the returned value is equal to the actual value if it is not modified, or the assigned value otherwise. (Use case: @everythingfunctional 's example)."

Should it be mentioned?

Copy link
Member

@certik certik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks good to me to be merged. We can further improve upon it.

@certik certik merged commit 07893ac into j3-fortran:master Feb 21, 2020
@certik
Copy link
Member

certik commented Feb 21, 2020

It seems there is general agreement on these changes. Further discussion might be needed on top, so let's open issues or further PRs as needed. I merged this, so that we have something in the repository that we can at least roughly agree on, and we can now work on polishing it up so that @zjibben can submit it as an official proposal.

In general, if we can't reach agreement, I think it is perfectly ok to simply propose the alternatives (with pros and cons) in the proposal, and let the committee discuss it and provide feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants