End of line inference algorithms are incredibly fragile, both by the compiler and by the human reader, having a semi-colon can make things clearer in the absence of another secondary signal (like indentation). There are so many type errors in scala or typescript that can be solved by adding a semicolon somewhere to eliminate some idiotic ambiguity.

Only-EOL like python is fine and always-semicolon like C is fine. Sometimes-optional but sometimes-required semicolon like Javascript is bad in my experience. Javascripts C-like syntax doesn't cope well with missing semicolons

> End of line inference algorithms are incredibly fragile

I am working on a language right now with optional semicolons (that is, newlines terminate statements unless there is a semicolon, which does the same early) and it’s not really that hard. The only change is that instead of looking for a newline character for statement termination I often also need to look for a semicolon.

> newlines terminate statements unless there is a semicolon, which does the same early

Since I'm writing a toy language with optional semicolons, I'm curious - how are you solving ambiguities in multi-line expressions? For example:

  1
  -1

Does your language not allow multi-line expressions, treating the above as two statements? Or, perhaps they must be explicitly an expression, like:

  (1
  -1)

I agree with you on another comment, that JavaScript's automatic semicolon insertion is complicated - so I'd like know if there's a sensible solution for languages without semicolons.

In this language, there's very few multi-line expressions. However, for your specific case: yes, I would consider that two statements.

  1 -
  1

would be one: putting a binary operator by itself in one line would cause the parser to keep looking.

Ah, I see, so new lines are like invisible operators (with low precedence) that ends a statement unless preceded by another operator. Right, that makes sense.

Python behaves "sensibly" with regard to this. Semicolons are statement breaks. Endlines are statement breaks, unless theres some reason for them not to be, such as being in a open brace state.

I think the issue is more when the new line doesn’t terminate the statement. Like in JS:

const a = doThing()

(() => throw Error)

JavaScript for some reason chose a very strange way to have its newlines work; a number of other languages have it figured out: Swift, for example.

Why not infer the end of a line when finding the end of a line? ;)

This is what most BASICs and assemblers did.

(I think QBasic had a line continuation character? - or maybe that came with Visual BASIC. I don't remember. But, anyway, if you wanted, it was possible to continue a source line past a line break, it just wasn't the default.)

I’m all for that option also, and we can always add an anti semi colon to write a multi line statement.