-
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
RFC: Tuple indexing #184
Changes from 1 commit
95561db
45e17a1
5946beb
e3c26d3
316a69f
9f146c1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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 }; | ||
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. It's not if the indexing is zero based. |
||
``` | ||
|
||
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. |
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