Hacker News Reader

Comment by masklinn | Hacker News Reader

The problem is not two expressions on one line, it’s one expression on two lines. e.g.

    foo
        .bar()

now you need to either add syntax to specify that you’re “continuing” (python), play tricks for the parser (Go), or have unreliable magic biting you in the ass half the time (javascript).

View on HN

It's not that difficult; just place the "." at the end of the line:

  foo.
    bar()

And that will work fine. At least in Go.

You can endlessly argue what location is better for the ".", but it really doesn't really matter. Regardless, you don't really need to do parser tricks.

That's exactly what I mean by parser trick. You're relying on the idea that if the parser sees an incomplete expression it won't end the statement then and there.

It also looks like shit, because now you have to check the end of the previous line to know whether it's a method call or a function call which was indented in incorrectly.

With gofmt it's always indented correctly.

Sure but that doesn't quite answer my question: is the parser trick really that bad?

I do see what you mean, of course, and am aware of the arguments but I've never found lack of non-whitespace expression terminator even remotely confusing. I can clearly see indentation in my periphery signalling that it's multi-line. I can also say that in ~13 of using exclusively using semicolon-less languages, I've never had or even heard of a problem caused by someone misunderstanding where an expression ends.

Anyway, this is getting pretty bikesheddy, lol but ya, to each their own, obviously.

I understand it's likely stupid in Python since it's whitespace significant, but are those Go parser tricks really such a big deal or even very tricky?

Reply on news.ycombinator.com