"Ternary-style if" doesn't work fully as intended

[ozra]

When using if with ternary style code-block delimiters, it of course still works as a regular if (doh!) which is not what one expects:

foo(x) -> "we got {x}"

bar = if true ? "True" : "False"      -- works fine
foo bla = if true ? "True" : "False"  -- works fine
foo (if true ? "True" : "False")      -- works fine
foo(if true ? "True" : "False")       -- also fine

foo if true ? "True" : "False"  -- not fine
                                -- here it is parsed as suffix if, not a ternary cond. 
                                -- errors since else is not (yet) allowed in suffix if

It could be fixed by:

1. Treating it as ternary-cond when ?/: is used (slightly more complex parse, but foremost confuzing)
2. Not fixing it - it's seen as an alternative block-delimiting, but if remains the same - use parentheses to disambiguate.
3. Ditching the if x ? a : b notation and replace with, say iff x ? a : b - to make it clearer that it's not suffix if (when used as argument as in the example)

I personally vote for along the lines of 3) - clarity of intent first.

[stugol]

No, I really don't like iff. I think solution 1. After all, if I write the code foo if true ? "True" : "False" I cannot possibly intend it to operate like a suffix-if, because suffix-ifs don't have an else clause, and they certainly don't have a then clause. And requiring parens is unhelpful - it's not ambiguous, so the programmer shouldn't have to disambiguate it!

Sure, it's maybe a little unclear to read, and maybe the programmer should consider adding parens for readability. But since when do we mandate readability in code?

Bottom line: If the code is valid, it should work. And the code is plainly a valid ternary-if.

[ozra]

Good arguments! Giving tools to easily write clear readable code is a motto to go by - not enforcing it! I'll let it simmer on for a while before we decide, as it's not a show stopper bug.