I also feel like if statements have room for improvement. I've expressed some ideas below. Even though it might not 100% align with the ideas of the Fuze team, I hope my chain of thought is useful anyway:
inline if statements IIF
If the arguments to a function call are conditional, I currently do not have many options. Basically I see two patterns:
pattern 1:
value = 1
if condition then
value = 2
endif
stuff(value)
pattern 2:
if condition then
stuff(2)
else
stuff(1)
endif
I would however like to use the inline if statement pattern (from other languages: stuff(condition ? 2 : 1)).
In F4NS I'd think a syntax like this would work:
stuff(IIF condition THEN 2 ELSE 1 ENDIIF)
IIF standing for 'inline if', and ending with ENDIIF in stead of ENDIF.
Fundamentally the difference is that an IIF must always decide on a statement that returns a value. Opposed to IF that executes conditionally.
keyword to prevent nesting ELSEIF
ELSEIF could easily be a keyword, that helps reduce the amount of nesting for correlated if statements (keeping the cognitive load of the code lower). This way only one ENDIF keyword would be needed for correlated conditions. It would be possible to follow up IF with multiple ELSEIF's and even one optional ELSE after those (ELSEIF would not be possible after ELSE).
For example:
string value
IF i < 0 THEN
value = "negative"
ELSEIF i > 0 THEN
value = "positive"
ELSE
value = "neutral"
ENDIF // using ELSEIF would not require an additional endif
stuff(value)
combining the two keywords
The following code could be reduced if we were allowed to combine those two keywords. Currently in F4NS you would write something like this:
string value
if i < 0 then
value = "negative"
else if i > 0
then
value = "positive"
else
value = "neutral"
endif
endif
stuff(value)
A possible option would be to introduce ELSEIIF (as an inline ELSEIF):
stuff( IIF i < 0 THEN "negative" ELSEIIF i > 0 THEN "positive" ELSE "neutral" ENDIIF)
Or otherwise IIF could be nested like so:
stuff(
IIF i < 0 THEN
"negative"
ELSE IIF i > 0
THEN
"positive"
ELSE
"neutral"
ENDIIF
ENDIIF
)
Type agnostic short circuiting
I guess you could name the following pattern "type agnostic short circuiting". It can be addictive, and this would work in JavaScript, but for F4NS this would probably be a bad idea:
stuff( (i < 0 && "negative") || ( i > 0 && "positive") || "neutral")
I know F4NS has the AND and OR keyword, but in my opinion it's more intuitive if those keywords would always resolve in a boolean value, where as && and || would then be able to resolve to other types (as shown in the example above).
