Amend RFC1228 with operator fixity and precedence

[nagisa]

#1228 left a pretty bikesheddable and important question unanswered: the fixity of the proposed operator.

Associativity is a no-brainer; precedence needs to be decided on.

[nagisa]

Something I noticed with option number 1, that it introduces an inconsistency in parsing between let x = y <- z; and x = y <- z. First one would get parsed as let x = (y <- z); and the other one as (x = y) <- z. This happens because let IDENT is a statement prefix that immediately tries to eat the initialiser. In light of that I changed the proposal to option number 3.

Also cc @pnkfelix.

[oli-obk]

You should add this downside to the text of proposal 1

[pnkfelix]

@nagisa where did the term "fixity" come from? Isn't this property usually referred as "precedence"? (When i hear "fixity" I usually think "infix vs prefix vs ...")

[nagisa]

@pnkfelix I fixed my terminology in some places some time ago, but forgot to commit and push it, apparently.

it comes from my background with haskell and “fixity” has the same meaning as “operator associativity”. That’s what writing RFCs late in the evening gets you ;)

[nikomatsakis]

Hear ye, hear ye. This RFC is now entering final comment period.

[nrc]

grammar nit: "This is what this RFC currently proposes"

[huonw]

It seems to me that <- is a variant of =, like - is a variant of +, which implies giving it the same precedence as = makes sense. What's the reasoning for option 3 in favour of option 2, it seems a bit arbitrary/undermotivated to me?

[nagisa]

@huonw x <- y may have a return value that’s not a () (mutable reference?), and it doesn’t really make much sense to do (a <- (b += (c <- d))) at all, but might make some sense to do (a <- b) += (c <- d). (remember += has same precedence and associativity as =)

The way I see it, at least.

[huonw]

@nagisa I feel that most cases will require *(a <- b) = ..., and anyway, writing a <- b += c <- d without any parens just seems confusing. I guess the question for me is whether writing such things is likely to result in code incorrectly compiling with the wrong meaning.

[nikomatsakis]

Huzzah! The @rust-lang/lang team has decided to accept this RFC. However, we also decided to add an official unresolved question to revisit this question when <- has achieved more usage, so that we can see what patterns are common and whether the precedence should be changed.