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

RFC: Tuple indexing #184

Merged
merged 6 commits into from
Sep 3, 2014
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions active/0000-tuple-accessors.md
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`.
Copy link
Contributor

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? And a.1.3 is just the same thing occuring twice.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As also pointed out on reddit, indexing as such (i.e. tuple[0], tuple[1] etc.) wouldn't make sense as an alternative, because tuples are heterogenous. (They definitely couldn't be made to implement the Index* traits.)


Unresolved questions
====================

None.