We were aware of those problems and specifically tried to avoid them in Swift's design, in several ways:
- Swift is statically typed, so an unexpected joining of statements is quite unlikely to type-check.
- Swift warns about ignoring the results of (most) expressions that produce non-
Voidvalues, so an unexpected splitting of statements is almost certain to be pointed out to the programmer. - Swift enforces the spacing rule everywhere, not just when it affects statement splitting; this forces programmers to be consistent about that style, making code that could lead to an unexpected splitting easier to see even without the help of a tool.
Because of all this, Swift's spacing rule is, at least in my opinion, just generally less likely to cause problems than the statement-separation rules used in most other languages. The nature of the rule means that the most likely mistake is that programmers accidentally split a statement by using inconsistent spacing around a binary operator. (It is very uncommon in practice to accidentally add spacing before/after an operator that's meant to be unary. There are also fairly few unary operators in Swift to begin with.) That's almost certain to lead to an immediate warning or error, and the text of that will be specifically about statement composition, not some sort of general "can't pass X to a Y" error that'll take a while to track back to the parsing problem.
I think the biggest downside is that programmers have to type more carefully even in interactive sessions (e.g. in the debugger) where they ordinarily wouldn't care about code style.