Prepare default value for optional arguments proposal for submission. #145
Conversation
| 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. |
There was a problem hiding this comment.
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 fooThere was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. | ||
| |
There was a problem hiding this comment.
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?
Co-Authored-By: Jeremie Vandenplas <jeremie.vandenplas@gmail.com>
Co-Authored-By: Jeremie Vandenplas <jeremie.vandenplas@gmail.com>
| 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. |
4 participants
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.