The point here is that what constitutes "parses exactly as it looks" means diametrically different things to you and to other people (including anyone coming from a great number of languages more commonly used than Swift): it's precisely this case that needs diagnostics.
Where the notation is ambiguous, people wouldn't be so certain of how they expect it to parse. Again, the purpose of this is to eliminate the "parses exactly as it looks" scenario. It's not about preventing people from writing ugly code, but from writing pretty code that means different things to different people.
Again, to make it plain, all of this design work is to address the following premise: There will be people who will see -x ** y
and confidently know it behaves as it does in Python and other languages, parsing the expression as -(x ** y)
; this represents a problem that must be addressed. If you accept this premise, then there are only three possibilities:
(1) do not introduce **
into the language at all;
(2) introduce **
but forbid the scenario in question from arising with diagnostics; or
(3) introduce **
but eliminate the mismatched expectations by aligning behavior with that of Python and other languages.
Option 1 is the status quo; option 2 is the design I've worked on in the PR toolchain; option 3 is what I've just described as impossible given the direction of Swift. That is an exhaustive list of options.
Alternatively, you can reject the premise, which is fine