-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: Tuple indexing #184
Merged
Merged
RFC: Tuple indexing #184
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
95561db
RFC: tuple accessors
ftxqxd 45e17a1
Fix indexing example to be zero-based
ftxqxd 5946beb
Improve semantics explanation
ftxqxd e3c26d3
More sensible ‘Alternatives’ section
ftxqxd 316a69f
Minor style & formatting fixes
ftxqxd 9f146c1
Add feature gate; remove special syntactic support for nested indices
ftxqxd File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
- Start Date: 2014-07-24 | ||
- RFC PR #: (leave this empty) | ||
- Rust Issue #: (leave this empty) | ||
|
||
Summary | ||
======= | ||
|
||
Add simple syntax for accessing values within tuples and tuple structs. | ||
|
||
Motivation | ||
========== | ||
|
||
Right now accessing fields of tuples and tuple structs is incredibly painful—one | ||
must rely on pattern matching alone to extract values. This became such a | ||
problem that twelve traits were created in the standard library | ||
(`core::tuple::Tuple*`) to make tuple value accesses easier, adding `.valN()`, | ||
`.refN()`, and `.mutN()` methods to help this. But this is not a very nice | ||
solution—it requires the traits to be implemented in the standard library, not | ||
the language, and for those traits to be imported on use. On the whole this is | ||
not a problem, because most of the time `std::prelude::*` is imported, but this | ||
is still a hack which is not a real solution to the problem at hand. It also | ||
only supports tuples of length up to twelve, which is normally not a problem but | ||
emphasises how bad the current situation is. | ||
|
||
Detailed design | ||
=============== | ||
|
||
Add syntax of the form `<expr>.<integer>` for accessing values within tuples and | ||
tuple structs. This syntax is recognised wherever an integer or float literal is | ||
found in place of the normal field or method name expected when accessing fields | ||
with `.`. Float literals in this position are expanded into two field accesses, | ||
so that an expression of the form `a.1.3` is equivalent to `(a.1).3`. | ||
|
||
Accessing a tuple or tuple struct field like so: | ||
|
||
```rust | ||
let x = (box 1i, box 2i); | ||
let x1 = x.1; | ||
``` | ||
|
||
is roughly equivalent to: | ||
|
||
```rust | ||
let x = (box 1i, box 2i); | ||
let x1 = { let (_, a) = x; a }; | ||
``` | ||
|
||
However, when taking a (possibly mutable) reference to a field, the equivalent | ||
expansion is slightly different: | ||
|
||
```rust | ||
let x = (box 1i, box 2i); | ||
let x1 = &x.1; | ||
``` | ||
|
||
is roughly equivalent to: | ||
|
||
```rust | ||
let x = (box 1i, box 2i); | ||
let x1 = { let (_, ref a) = x; a }; | ||
``` | ||
|
||
A similar process is performed with `&mut`. | ||
|
||
Drawbacks | ||
========= | ||
|
||
More complexity that is not strictly necessary. | ||
|
||
Alternatives | ||
============ | ||
|
||
Allow indexing of tuples and tuple structs: this has the advantage of | ||
consistency, but the disadvantage of not being checked for out-of-bounds errors | ||
at compile time. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As also pointed out on reddit, indexing as such (i.e. |
||
|
||
Unresolved questions | ||
==================== | ||
|
||
None. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that
a.1.3
should be legal and equivalent to(a.1).3
, but isn't there a way to do this without introducing the awkwardness of float literals in the first place? I.e. just say that valid tokens following the.
operator are either an identifier (named struct field, method) or a decimal number? Anda.1.3
is just the same thing occuring twice.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@glaebhoerl I would imagine (I am not well aquainted with the internals of the rust compiler) that float literals become involved because this RFC would probably be implemented by modifying the parser, whereas float literals are a type of token output by the lexer (since the lexer typically doesn't have much of a notion of context).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1