Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amend RFC1228 with operator fixity and precedence #1319

Merged
merged 2 commits into from Apr 22, 2016

Conversation

Projects
None yet
9 participants
@nagisa
Copy link
Contributor

commented Oct 13, 2015

#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 nagisa force-pushed the nagisa:placement-fixity branch 3 times, most recently from a8385ef to fccb3b2 Oct 13, 2015

@nagisa

This comment has been minimized.

Copy link
Contributor Author

commented Oct 14, 2015

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.

@nagisa nagisa force-pushed the nagisa:placement-fixity branch from fccb3b2 to 1f0fb30 Oct 14, 2015

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2015

You should add this downside to the text of proposal 1

@nagisa nagisa force-pushed the nagisa:placement-fixity branch from 1f0fb30 to 4958c86 Oct 14, 2015

@nrc nrc added the T-lang label Oct 15, 2015

@nikomatsakis nikomatsakis assigned pcwalton and pnkfelix and unassigned pcwalton Oct 15, 2015

@pnkfelix

This comment has been minimized.

Copy link
Member

commented Oct 15, 2015

@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 nagisa force-pushed the nagisa:placement-fixity branch from 4958c86 to 33775e6 Oct 15, 2015

@nagisa

This comment has been minimized.

Copy link
Contributor Author

commented Oct 15, 2015

@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 ;)

@nagisa nagisa changed the title Amend RFC1228 with operator fixity Amend RFC1228 with operator fixity and precedence Oct 15, 2015

@aturon aturon added the I-nominated label Mar 10, 2016

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2016

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


3. More than assignment and binop-assignment, but less than any other operator:

This is what currently this RFC proposes. This allows for various

This comment has been minimized.

Copy link
@nrc

nrc Apr 4, 2016

Member

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

@huonw

This comment has been minimized.

Copy link
Member

commented Apr 7, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 7, 2016

@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

This comment has been minimized.

Copy link
Member

commented Apr 7, 2016

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2016

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.

nikomatsakis added a commit to nikomatsakis/rfcs that referenced this pull request Apr 22, 2016

@nikomatsakis nikomatsakis merged commit 98dd9e4 into rust-lang:master Apr 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.