For confirmation, is the “?” form mentioned by various people and in various proposal texts mean the “???” form (i.e., “?” form (21-157) in the first post of this thread)? I first misunderstood that @sblionel referred to the usual “?” ternary form, but later I noticed it may mean the “???” form (21-157).
Also, the reason why this unusual form was proposed is for the need to handle
fixed-source form? (because keywords can appear in a concatenated way with other
variable names etc, so some special “delimiter” is needed etc).
This is NOT saying it is identical to the C (and PHP and other) forms - only that the use of ? is recognizable as indicating a conditional expression. -> is sometimes a pointer dereference or structure component reference in other languages, and I think would be confusing to use in Fortran for conditional expressions.
I’m not keen on the function-like syntax being proposed as an alternative because while it looks like a function it doesn’t behave like one. 21-165 doesn’t discuss what happens if a user-declared function or generic interface ifthen exists. I would much rather see a distinctive syntax here.
While I do not have any experience in a language standardization process and the development of compilers, I agree that the ???-Notation is hard to read and is a bit in the “uncanny valley” between being similar to the C notation and having a different syntax.
This might it actually make it even harder to understand for people with experience in a C-like language (I guess most Fortran programmers also have at least had some contact with C-like languages).
Allowing ?(a>b,x,y) as I suggested above would avoid this problem since ? cannot appear in a function name. Fortran does have non-function statements such as allocate, deallocate, open, close, inquire where the “arguments” appear inside parentheses, although they don’t return a value unlike the proposed ?.
I generally agree, but wonder whether MERGE is not kind of an “false friend” to conditional expressions as it works on a component basis, which would not be the case for conditional expressions.
res = ifthen(x >= 0.0, sqrt(x), -0.0)
res = ifthen(present(x), a, ifthen(present(b), b, 0))
res = ifthen(present(x), x, ifthen(present(y), y,
ifthen(present(z), z, 0)))
would look like using the ?() syntax:
res = ?(x >= 0.0, sqrt(x), -0.0)
res = ?(present(x), a, ?(present(b), b, 0))
res = ?(present(x), x, ?(present(y), y, ?(present(z), z, 0)))
Good points @sblionel about a user-declared function or generic interface ifthen.
I’m glad it was possible to vote for two. I voted for the keyword and arrow forms. I have a slight preference for the keyword form because I imagine it to be immediately obvious as plain English. My love for compactness makes the arrow form a close second choice, although I wish we could replace “->” with “=>” because of the horizontal symmetry – is that not possible because of confusion with pointer assignment? I strongly dislike the “?” on aesthetic and opaqueness grounds. From the other comments, I gather that it resembles C/C++, but outside of high-performance computing settings, I think more programmers come to Fortran with Python experience than with C/C++ experience these days so the similarity to C/C++ is not so compelling in my view.
For anyone interested, merge can be a substitute for conditional expressions in most cases that matter for my purposes, but merge suffers from several limitations that conditional expressions will remove.
IMHO, Fortran should keep standing for FORmula TRANslation
and remain syntax-wise readable/accessible to beginners and occasional users.
Other prominent languages have fancy one-liners that are virtually un-understandable by non experts, and I strongly recommend Fortran does not even make a single step into that direction.
I voted “Other”: I believe the existing, long-winded syntax is much more readable for complex cases and I do not think that this single, isolated feature (even if perfectly designed) will make Fortran less verbose. I would suggest to use the limited time and resourced of the committee on far higher-yield, important and useful features.
Such potential convenience functionalities might be left to the stdlib developers, if there is enough interest.
This seems like the best argument for using an intrinsic function. Their actual arguments are (I think) the only place in the language where a subexpression of an expression is not necessarily evaluated.
Similarly, Fortran has syntax like RESULT( ) and BIND( ) that are clearly not functions. While people can argue about the spelling of “ifthen”, I think the “looks like a function” argument is weak at best.
With both I would hope the semantics can be included for elemental usage.
And I really hope the standard-bearers don’t end up “kicking the can down the road” and do indeed end up introducing a good facility toward conditional expressions this time around in Fortran 202X, for there is enough of a need toward such a conditional expression in scientific and technical computing to warrant attention here. And for everyone to be also caring and inclusive i.e., to help and support the development and introduction of such a facility in the language. The long-form syntax will always be there for anyone bothered by the terseness of an intrinsic conditional expression facility.
Although that is on the agenda for 2X to short-circuit operators (in some form). I don’t have an opinion on that in terms of performance — I am thinking even if it gets short-circuited, the compiler can generate a warning if it thinks some different order would be more efficient.