Parsing issue for composed return value with =>

[KlausC]

julia> f1() = begin 0:-1, ""=>"" end;

julia> f2() = begin (0:-1, ""=>"") end;

I expected the same return type for both functions, but:

julia> typeof(f1())
Pair{Tuple{UnitRange{Int64},String},String}

julia> typeof(f2())
Tuple{UnitRange{Int64},Pair{String,String}}

julia> typeof((0:-1, ""=>""))
Tuple{UnitRange{Int64},Pair{String,String}}

julia> typeof(((0:-1, ""=>"")))
Tuple{UnitRange{Int64},Pair{String,String}}

julia> typeof(((0:-1, "")=>""))
Pair{Tuple{UnitRange{Int64},String},String}

It looks like the comma "operator" in a,b has precedence before the => operator.
IMO that is not to be expected and a parsing issue, because the consequence is, that parens
around an expression can change the meaning.
With my restricted insight, I cannot imagine a reason for comma needing a high precedence, when
it appears outside a parenthesized list.

PS: its the same with assignments x1 = 0:-1, ""=>"" etc.

[JeffBezanson]

The reason for this is to parse a, b = c as (a, b) = c, and => has traditionally had assignment-like precedence. There is some history in #12285. The most recent suggestion is to give => its own precedence level higher than = but lower than everything else. That was never done, but maybe we should do it now? I kind of like the idea.

[JeffBezanson]

That change would only break a => b = c, which I imagine is basically never used. It currently parses as a => (b = c), which is weird, since (a => b) = c would be more useful (for destructuring).

[KlausC]

I had the idea, that arith/logical ops stronger => stronger than , stronger than = outside of argument lists/tuples.
Inside argument lists, => stronger = stronger , .
That would have the effect, that expressions not containing = or less binding did not change meaning, if wrapped into () - they remained tuples, if separated by ,.