Poll: Fortran 202X Conditional Expressions syntax

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.

Relevant papers:

Relevant discussion threads:

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.

“?” form (21-157)

(? cond ? expr :? cond2 ? expr2 : expr3 ?)

Ditto, conditional arg with optionality:

(? cond ? arg :? cond2 ? arg2 ?) ! else absent arg

Arrow ("->") form (21-159)

( predicate -> consequent
  [ : predicate -> consequent ] ...
    : alternative )


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

0 voters


I voted “other” for my suggestion :slight_smile:

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 for the Arrow (->) form and Other: ifthen() or similar new intrinsic.

1 Like

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.

1 Like

I voted “other”. I find these syntaxes hard to read.

1 Like

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.

1 Like

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.


Welcome @JoGebert!

I like the arrow syntax. If you read it a few times it starts to feel quite natural and is suitably concise to be useful.

Having said that, the way Python does it (expr first) is my favourite way of doing it as the code reads more like you would say it in person:

x = 2/y if y != 0 else 0

But I suspect that would introduce difficulties with Fortran’s syntax.

1 Like

I voted “Other”.

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.

1 Like

@samharrison7, @mleair, @zjibben thanks for your vote, your comment and welcome to the forum!


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.


Voted for keyword and also other, I think ifthen() as suggested by others would be worth exploring.

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.


Vote for the arrow syntax.