GitLab

Not sure, if it is worth it to break things. However I think it is bad practice the least.

feat: Simplification of ;
; means in the context of loops start and end body
; means in the context of matches start of body (which always has a newline)
; means in the context of assignments linear separation
It would be easier, if ; has only an effect on the current line and would also simplify the language analysis+readability.

BREAKING CHANGE: Deprecate code with ; inside logical control statements, which are not not single liners. These are currently not used in the book, but may work from time to time #869 .

perf: impact

performance
After discussion no big performance is expected.

usability Users are used to annotate

# the end statements is "overhead", but otherwise we need python indentation
for an in @split("a b c")
  echo $an
end

in additional 3 other ways:

# have fun identifying all endings of the loop in nested cases
for a1 in @split("a b c")
  echo $a1; end

for a in @split("a b c"); echo $a
end
# if this is allowed, then also
for a in @split("a b c"); for a in @split("a b c"); echo $a
end
end
# => inconsistent rule 

**# all or nothing**
for a in @split("a b c"); echo $a; end
match $a:
   case [ "a" "b" "c" ]; echo "yay"
end
**# but also **
match $a: case "a"; echo "boo"; case "b"; echo "boo"; case "c"; "boo"; end

maintainability marginally better

reason: Inconsistency is bad for learning and setting up things and code review for shell code

behavior of bash/dash/zsh/fish/oil bash supports the syntax with ; at arbitrary positions
dash supports the syntax with ; at arbitrary positions
zsh supports the syntax with ; at arbitrary positions
fish supports the syntax with ; at arbitrary positions
oil shell does not link a syntax definition or book, the help is poor and the man page broken