From 95561dbf34ab59954d28324066abf4bb934b2bda Mon Sep 17 00:00:00 2001 From: P1start Date: Thu, 24 Jul 2014 23:03:40 +1200 Subject: [PATCH 1/6] RFC: tuple accessors --- active/0000-tuple-accessors.md | 80 ++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 active/0000-tuple-accessors.md diff --git a/active/0000-tuple-accessors.md b/active/0000-tuple-accessors.md new file mode 100644 index 00000000000..671477a57e2 --- /dev/null +++ b/active/0000-tuple-accessors.md @@ -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 `.` 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. + +Unresolved questions +==================== + +None. From 45e17a1aae3ca7435d67b80f0e51538935a1ce43 Mon Sep 17 00:00:00 2001 From: P1start Date: Thu, 24 Jul 2014 23:37:31 +1200 Subject: [PATCH 2/6] Fix indexing example to be zero-based --- active/0000-tuple-accessors.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/active/0000-tuple-accessors.md b/active/0000-tuple-accessors.md index 671477a57e2..3cfd545b7d3 100644 --- a/active/0000-tuple-accessors.md +++ b/active/0000-tuple-accessors.md @@ -42,7 +42,7 @@ is roughly equivalent to: ```rust let x = (box 1i, box 2i); -let x1 = { let (a, _) = x; a }; +let x1 = { let (_, a) = x; a }; ``` However, when taking a (possibly mutable) reference to a field, the equivalent @@ -57,7 +57,7 @@ is roughly equivalent to: ```rust let x = (box 1i, box 2i); -let x1 = { let (ref a, _) = x; a }; +let x1 = { let (_, ref a) = x; a }; ``` A similar process is performed with `&mut`. From 5946beb1281d90ea1971fe6a70e9edd50f7e05df Mon Sep 17 00:00:00 2001 From: P1start Date: Fri, 25 Jul 2014 15:36:02 +1200 Subject: [PATCH 3/6] Improve semantics explanation --- active/0000-tuple-accessors.md | 50 ++++++++++++++-------------------- 1 file changed, 20 insertions(+), 30 deletions(-) diff --git a/active/0000-tuple-accessors.md b/active/0000-tuple-accessors.md index 3cfd545b7d3..981f0d4513f 100644 --- a/active/0000-tuple-accessors.md +++ b/active/0000-tuple-accessors.md @@ -26,41 +26,31 @@ Detailed design =============== Add syntax of the form `.` 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`. +tuple structs. This syntax is recognised wherever an unsuffixed 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: +Tuple/tuple struct field access behaves the same way as accessing named fields +on normal structs: ```rust -let x = (box 1i, box 2i); -let x1 = x.1; +// With tuple struct +struct Foo(int, int); +let mut foo = Foo(3, -15); +foo.0 = 5; +assert_eq!(foo.0, 5); + +// With normal struct +struct Foo2 { _0: int, _1: int } +let mut foo2 = Foo2 { _0: 3, _1: -15 }; +foo2._0 = 5; +assert_eq!(foo2._0, 5); ``` -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`. +Effectively, a tuple or tuple struct field is just a normal named field with an +integer for a name. Drawbacks ========= From e3c26d33d7d927cdde3a94f8de051ced4efdbb50 Mon Sep 17 00:00:00 2001 From: P1start Date: Mon, 28 Jul 2014 15:28:32 +1200 Subject: [PATCH 4/6] =?UTF-8?q?More=20sensible=20=E2=80=98Alternatives?= =?UTF-8?q?=E2=80=99=20section?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Indexing of tuples makes no sense because not all tuples are homogenous. --- active/0000-tuple-accessors.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/active/0000-tuple-accessors.md b/active/0000-tuple-accessors.md index 981f0d4513f..91cb0301a79 100644 --- a/active/0000-tuple-accessors.md +++ b/active/0000-tuple-accessors.md @@ -60,9 +60,11 @@ 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. +Stay with the status quo. Either recommend using a struct with named fields or +suggest using pattern matching to extract values. If extracting individual +fields of tuples is really necessary, `the `TupleN` traits could be used +instead, and something like `#[deriving(Tuple3)]` could possibly be added for +tuple structs. Unresolved questions ==================== From 316a69f7327359bd36f155f35d89b4dbab3d0d97 Mon Sep 17 00:00:00 2001 From: P1start Date: Mon, 28 Jul 2014 15:32:30 +1200 Subject: [PATCH 5/6] Minor style & formatting fixes --- active/0000-tuple-accessors.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/active/0000-tuple-accessors.md b/active/0000-tuple-accessors.md index 91cb0301a79..c639f4491ed 100644 --- a/active/0000-tuple-accessors.md +++ b/active/0000-tuple-accessors.md @@ -11,7 +11,7 @@ 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 +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 @@ -55,16 +55,16 @@ integer for a name. Drawbacks ========= -More complexity that is not strictly necessary. +This adds more complexity that is not strictly necessary. Alternatives ============ Stay with the status quo. Either recommend using a struct with named fields or -suggest using pattern matching to extract values. If extracting individual -fields of tuples is really necessary, `the `TupleN` traits could be used -instead, and something like `#[deriving(Tuple3)]` could possibly be added for -tuple structs. +suggest using pattern-matching to extract values. If extracting individual +fields of tuples is really necessary, the `TupleN` traits could be used instead, +and something like `#[deriving(Tuple3)]` could possibly be added for tuple +structs. Unresolved questions ==================== From 9f146c16f02f25a8e42c7654f3886ea8df407bff Mon Sep 17 00:00:00 2001 From: P1start Date: Wed, 27 Aug 2014 15:10:22 +1200 Subject: [PATCH 6/6] Add feature gate; remove special syntactic support for nested indices --- active/0000-tuple-accessors.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/active/0000-tuple-accessors.md b/active/0000-tuple-accessors.md index c639f4491ed..cc8f97184d3 100644 --- a/active/0000-tuple-accessors.md +++ b/active/0000-tuple-accessors.md @@ -5,7 +5,8 @@ Summary ======= -Add simple syntax for accessing values within tuples and tuple structs. +Add simple syntax for accessing values within tuples and tuple structs behind a +feature gate. Motivation ========== @@ -26,11 +27,12 @@ Detailed design =============== Add syntax of the form `.` for accessing values within tuples and -tuple structs. This syntax is recognised wherever an unsuffixed 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`. +tuple structs. This (and the functionality it provides) would only be allowed +when the feature gate `tuple_indexing` is enabled. This syntax is recognised +wherever an unsuffixed integer literal is found in place of the normal field or +method name expected when accessing fields with `.`. Because the parser would be +expecting an integer, not a float, an expression like `expr.0.1` would be a +syntax error (because `0.1` would be treated as a single token). Tuple/tuple struct field access behaves the same way as accessing named fields on normal structs: