Skip to content

Consider making pointer boxing a higher priority #5144

New issue

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

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

Already on GitHub? # to your account

Closed
Kimundi opened this issue Feb 27, 2013 · 3 comments
Closed

Consider making pointer boxing a higher priority #5144

Kimundi opened this issue Feb 27, 2013 · 3 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-grammar Area: The grammar of Rust

Comments

@Kimundi
Copy link
Member

Kimundi commented Feb 27, 2013

Right now, ~[1,2,3].to_str() is the same as ~([1,2,3].to_str()), which is confusing because in the case of of strings and vectors, the sigil is basically part of the literal.

If pointer boxing gets at least a higher priority than method application, ~[1,2,3].to_str() would mean (~[1,2,3]).to_str(), and you'd have to add explicit delimiters to box the whole method chain, like so: ~([1,2,3].to_str())

Which, I think, would be more intuitive: A pointer sigil puts the thing right next to it in a box, if you want to box the result of an complex operation, but it in brackets.

@catamorphism
Copy link
Contributor

Seems non-critical for 0.7. Nominating for milestone #1.

@graydon
Copy link
Contributor

graydon commented May 2, 2013

rejected as wontfix; it's not great but unary operators are low-precedence by design

@nikomatsakis
Copy link
Contributor

I prefer to keep all unary operators with the same precedence, and I prefer to use C's precedence rules, so that &a.b.c continues to work.

@graydon graydon closed this as completed May 2, 2013
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-grammar Area: The grammar of Rust
Projects
None yet
Development

No branches or pull requests

4 participants