Can anyone give a good reason why supporting syntax like:
y = 2 * x
- 3
y = 2 * x
- 3
such as applicative style formatted like this:
f
<$> x
<*> y
<*> zSo, the question is, if you have a long expression, should you have to worry too much about either adding parentheses, or making sure that your line break occurs inside a pair of parentheses.
It boils down to preference, but a language feature that supports whatever preference you have might be nice.
priority = "URGENT" if hours < 2 else
"HIGH" if hours < 24 else
"MEDIUM" if hours < 72 else
"LOW" if object.method()
|| other_object.field.condition()
|| (foo > bar && baz < qux)Because it's very little extra work.
If you want to know if it's a good syntax, AFAIK it's the only way to do a semicolon-less language that doesn't break all the time.
If it ever gets to that point, a refactor is obligatory.
Don't give the human tools to make easy mistakes. Any grammar can be abused, so blame the human for not writing clean code.
Semicolons are just noise. They're absolutely redundant.
Some brackets are necessary, but whitespace/indent languages make it clear there's a lot of redundancy there too.
The goal is to minimise errors and cognitive load. The fewer characters the better.
The only purpose for whitespace indentation is to make the code easier on the eyes. A space shouldn't have an impact in terms of execution, that would be too hazardous. It's too easy to randomly insert a space rather than a character.
What are you doing with your code? I never find myself just randomly inserting characters.
Hasn't it ever occured to you trying to insert a space at your mouse but your cursor wasn't there? People sometimes forget to click (or think the cursor is already there), myself included. Characters are easier to spot because they are not invisible and random letters cause compile errors.
If it has never occurred to you, then good for you. However I do not see what the benefit of not using closing brackets would be.
> I do not see what the benefit of not using closing brackets would be.
Less visual noise. And the ability to use braces for other syntax.
Fair point.
> Less visual noise.
It doesn't solve this problem of your eyes guessing the correct indentation, especially when using two spaces (I hate two spaces even with braces). You could set up your IDE so it highlights the block and prints a hint at the end what block is ending, however you lose this once you open a plain text editor.
The point of using braces for this is that you can count them.
Also, if you were to print the code without braces on a paper, it would be a hard time reading, since the paper is much smaller than a 27" monitor.
> And the ability to use braces for other syntax.
There's other ways. For example, {} in Swift can be also used for ResultBuilder. And if you need the braces without knowing the type upfront, you can prefix it e.g. ${}.
I'd reckon that in a language where stuff is done by indentation but optional braces exist that are just ignored so many errors would also have been caused by braces being misplaced by the programmer to queue other programmers who thought some scope happened as a consequence but the compiler disagreed due to the indentation, which by the way was caused by tabs and spaces being mixed in the code and it not properly showing up for another programmer with tab with set differently.
Python banned this in python3. Problem solved.
Make your IDE highlight the current section or display a hint showing starting bracket. For example, C++ devs do #endif // #if ...
Too many brackets? Refactor - problem solved.
In PowerShell you can do that by explicitly instructing what the next line is actually a continuation of the previous one:
$y = 2 * $x `
- 3