J3 and WG5 will vote on Monday, June 28 on two proposals for conditional expressions to be added as a feature to Fortran 202X. This poll aims to gather feedback from members of the Fortran community here. We will present the results of the poll to the Committee on Monday.
21-157 proposes two forms, the keyword form or the “?” form. 21-159 proposes the arrow ("->") form. Sections below summarize only the proposed syntax in two papers.
Keyword form (21-157)
if ( cond ) then ( expr ) elseif ( cond2 ) then ( expr2 ) else ( expr3 ) endif
Ditto, conditional arg with optionality:
if ( cond ) then ( arg ) elseif ( cond2 ) then ( arg2 ) endif ! else absent arg
See examples of this form in a Jupyter Notebook as prototyped in LFortran.
This is a multiple choice poll. Please review the linked papers and discussion threads before casting a vote. If you chose “Other”, please specify by writing a comment below.
The keyword form
The ? form
The arrow (->) form
Other: Do not add this feature, or, pursue alternative forms (write in comment).
I voted “Other”. I think all the proposed syntaxes are hard to read, except in the simplest, most trivial use cases. I think pursuing a function-call-like syntax is better, like merge but with relaxed rules about when arguments need to be evaluated (see: https://github.com/j3-fortran/fortran_proposals/issues/183#issuecomment-703772191 and subsequent discussion)
I also voted Other. I think the 3 proposed syntax options are not very readable. In a case like this, I think it’s better not to add the feature in the first place, or wait for a better proposal to be submitted. The intrinsic function ifthen seems like a promising option.
I voted “Other” because I feel I won’t use any of these syntax if available, too verbose or too complicated to read.
I like the C syntax and sometimes use it because it is concise, and quite easy to read (once you have learned it). But if it is not concise and readable, why would I use it?
I voted for the arrow syntax - it’s concise and readable.
I also voted other because I really don’t like the “keyword” and ‘?’ forms. Both are hard to parse (for my human brain) and I would hate to be faced with having to debug such code. Their acceptance would IMHO be a backward step for the language - I’d much rather the time were spent on generic programming capabilities.
I voted for the arrow syntax and other. I might get used to the arrow since it felt similar to cond in racket (and others) but I feel like I’d prefer the original existing forms for all the examples mentioned.
Option 1 provides the best readability from them. However, it gets complex pretty quickly. And we can cirument it with existing structures. I Understand if someone likes to opt against this feature.
I prefer the idea of a special-case behavior for MERGE when the MASK= is scalar and the first two arguments have same type/kind/rank. Or it could be a new intrinsic. This is also discussed in https://github.com/j3-fortran/fortran_proposals/issues/183
I voted other. My favorite is to just modify merge as @mleair suggested, or perhaps add a new intrinsic. I’m also ok with Python’s syntax, which can be written like piecewise functions:
f = a if x < 0 \
else b if x < 10 \
else c
I’d also be OK with the plain C ternary, so long as it isn’t required to be decorated with (? ?).
But realistically, I’m not sold this feature is important enough to add new syntax for, especially not completely novel syntax. merge works for most cases, and if we add defaults for optional arguments that takes care of lots of the other cases.
I voted other. These are all too ugly. Too verbose, too many “?” (someone loves question marks). I’d prefer a special scalar case of merge, or even C’s ternary operator syntax. I’m dubious that the usefulness of the more complex conditional expressions (things beyond if-then-else) outweigh the unreadability of these statements.
I voted other. Completely unnecessary changes should be avoided. All this accomplishes is adding work for compiler developers and further complicating Fortran which is already a very rich language. I have one message to the committee. Please stop making changes that are not truly needed. It leaves a perception of just seeking some pet feature. Not something the community really needs. (others might use the description “not in touch with reality”)
It hardly matters which one you choose, developers will get used to the syntax. But, I agree with @JerryD . The standards committee should focus on features which have no equivalent in standard Fortran. For example, developers are forced to use non-standardized prepocessors for implementing generics. I don’t like unnecessary inflation of standards with features already covered by an alternative syntax. Also, I favour generalizing the syntax already in place, MERGE in the present case, to new use cases.
Further, I feel that optimizations like lazy evaluation, tail call optimization, compile time evaluations etc, which can be easily inferred, should be a part of the standard.
