That said, I agree the changes to function type ascriptions are the most contentious part. And I notice the problems arise only if we accept : lambda on a single line. If we always require an indent after =>, the ambiguity goes away in practice, and we could keep the previous parser behavior. Maybe a SIP could then try to spec that behavior, but that’s another topic.
So, what about we do not allow : lambda on a single line? I.e. this is OK:
xs.map: x =>
x + 1
But this would now be an error:
xs.map: x => x + 1
The downside is that refactoring a lambda to be on a single line is something you want to do.
The upside is that we avoid the ambiguities with type ascriptions – which don’t apply formally in the grammar but do apply for the parser behavior and do apply visually. For instance:
foo(bar: baz => bam)
Is it a type ascription or a lambda? Yes, we often have upper/lowercase to tell, but it does feel fragile.
The other upside is that it would establish : firmly as a convention linked to indentation. I.e.
transactional:
send(msg)
cannot be replaced by transactional: send(msg), so why should we have a different expectation if transactional: is followed by x => or something like it?
In other words, fewerBraces is about dropping braces, not parentheses. Instead of xs.map: x => x + 1 you should just keep writing xs.map(x => x + 1). There’s no point in having multiple ways to do it, with no clear guidelines which is better.
I’ll refactor my PRs so that we can study both options.