From 32f6d0b170dccc324a563a091c926c3a25a294ce Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 2 Jun 2014 12:33:19 -0400 Subject: [PATCH 1/4] copy template --- active/0000-homogenous-tuples.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 active/0000-homogenous-tuples.md diff --git a/active/0000-homogenous-tuples.md b/active/0000-homogenous-tuples.md new file mode 100644 index 00000000000..629e4e4a37e --- /dev/null +++ b/active/0000-homogenous-tuples.md @@ -0,0 +1,29 @@ +- Start Date: (fill me in with today's date, YYYY-MM-DD) +- RFC PR #: (leave this empty) +- Rust Issue #: (leave this empty) + +# Summary + +One para explanation of the feature. + +# Motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +# Detailed design + +This is the bulk of the RFC. Explain the design in enough detail for somebody familiar +with the language to understand, and for somebody familiar with the compiler to implement. +This should get into specifics and corner-cases, and include examples of how the feature is used. + +# Drawbacks + +Why should we *not* do this? + +# Alternatives + +What other designs have been considered? What is the impact of not doing this? + +# Unresolved questions + +What parts of the design are still TBD? From e7b3d36edddcd40e2cb1456253be493ccfc7a353 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 2 Jun 2014 12:45:38 -0400 Subject: [PATCH 2/4] Proposal to add methods to homogeneous tuples so that they can be used as slices. --- active/0000-homogeneous-tuples.md | 95 +++++++++++++++++++++++++++++++ active/0000-homogenous-tuples.md | 29 ---------- 2 files changed, 95 insertions(+), 29 deletions(-) create mode 100644 active/0000-homogeneous-tuples.md delete mode 100644 active/0000-homogenous-tuples.md diff --git a/active/0000-homogeneous-tuples.md b/active/0000-homogeneous-tuples.md new file mode 100644 index 00000000000..79af25d2216 --- /dev/null +++ b/active/0000-homogeneous-tuples.md @@ -0,0 +1,95 @@ +- Start Date: (fill me in with today's date, YYYY-MM-DD) +- RFC PR #: (leave this empty) +- Rust Issue #: (leave this empty) + +# Summary + +Add methods to allow homogeneous tuples (e.g., `(T, T, T)`) to be used +as slices (`&[T]`). + +# Motivation + +Homogeneous tuples and fixed-length arrays have the same memory +layout, but provide distinct capabilities. Tuples are particularly +useful because they can be split apart into their componenet parts: + + let (a, b, c) = tuple; + +On the other hand, fixed-length arrays support indexing, which is +great for writing generic code: + + for i in range(0, fixed_length.len()) { ... fixed_length[i] ... } + +I have found that in many cases I would prefer a tuple type, because I +am managing a tuple of distinct cases that I would like to be able to +destructor and reassign, but I would also sometimes like to use +indexing to avoid code duplication. + +In this RFC, therefore, I augment tuple types with the ability to +support indexing and in general act as slices. This means that tuples +are a better choice than fixed-length arrays for those cases where one +intends to pull apart the tuple at some point. + +# Detailed design + +Add the following traits for tuples of sizes 2 to 16 whose component +type is `$T`: + +``` +pub trait $Tuple<$T> { + /// Number of elements in the tuple. + fn len(&self) -> uint; + + /// A slice pointing onto the tuple. + fn as_slice<'a>(&'a self) -> &'a [$T]; + + /// A mutable slice pointing onto the tuple. + fn as_mut_slice<'a>(&'a mut self) -> &'a mut [$T]; + + /// Iterate through the elements of the tuple. + fn iter<'a>(&'a self) -> Items<'a, $T>; + + /// Iterate through the elements of the tuple. + fn mut_iter<'a>(&'a mut self) -> MutItems<'a, $T>; + + /// Index into the tuple. + fn get<'a>(&'a self, index: uint) -> &'a $T; + + /// Index mutably into the tuple. + fn get_mut<'a>(&'a mut self, index: uint) -> &'a mut $T; +} +``` + +The implementation of `as_slice` and `as_mut_slice` is done by simply +creating a slice pair and transmuting. All other methods can be +derived by invoking the appropriate method on the slice type. + +# Drawbacks + +None of which I am aware. + +# Alternatives + +1. Make fixed-length arrays a supertype of homogeneous tuples. More + precisely, `(T_1, ..., T_n)` would be a subtype of `[U, ..n]` if + `forall i. T_i <: U`. This is elegant but would be a deeper change + for something that rarely comes up in practice. I am not sure of + the full repercussions. + +2. Make fixed-length patterns more-expressive so that they can easily + support moves. In other words, people might write: + + let [a, b, c] = fixed_length; + + instead of + + let (a, b, c) = tuple; + + This may be a good idea, and we do need to put some effort post-DST + into rationalizing vector patterns, but is basically independent + from this RFC. That is, doing this RFC doesn't preclude us from + improving vector patterns, nor does it make it any harder. + +# Unresolved questions + +None. diff --git a/active/0000-homogenous-tuples.md b/active/0000-homogenous-tuples.md deleted file mode 100644 index 629e4e4a37e..00000000000 --- a/active/0000-homogenous-tuples.md +++ /dev/null @@ -1,29 +0,0 @@ -- Start Date: (fill me in with today's date, YYYY-MM-DD) -- RFC PR #: (leave this empty) -- Rust Issue #: (leave this empty) - -# Summary - -One para explanation of the feature. - -# Motivation - -Why are we doing this? What use cases does it support? What is the expected outcome? - -# Detailed design - -This is the bulk of the RFC. Explain the design in enough detail for somebody familiar -with the language to understand, and for somebody familiar with the compiler to implement. -This should get into specifics and corner-cases, and include examples of how the feature is used. - -# Drawbacks - -Why should we *not* do this? - -# Alternatives - -What other designs have been considered? What is the impact of not doing this? - -# Unresolved questions - -What parts of the design are still TBD? From bb265a37dc27d39552a44501afd69213e6918002 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 2 Jun 2014 12:53:58 -0400 Subject: [PATCH 3/4] Add a note about coercion --- active/0000-homogeneous-tuples.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/active/0000-homogeneous-tuples.md b/active/0000-homogeneous-tuples.md index 79af25d2216..441fd66d037 100644 --- a/active/0000-homogeneous-tuples.md +++ b/active/0000-homogeneous-tuples.md @@ -76,7 +76,15 @@ None of which I am aware. for something that rarely comes up in practice. I am not sure of the full repercussions. -2. Make fixed-length patterns more-expressive so that they can easily +2. As above, but use coercion. This is actually a somewhat smaller + change though I am reluctant to do anything but tighten coercion + rules for the time being. In particular I do not want to add ad-hoc + rules because I hope to leave space for something more + user-extensible in the future. In the event that these coercions + become automatic, these tuple traits could probably be removed, or + at least deprecated. + +3. Make fixed-length patterns more-expressive so that they can easily support moves. In other words, people might write: let [a, b, c] = fixed_length; From a18ec243c58aa2100e06e928f695c672bf4e4d7f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 2 Jun 2014 14:50:32 -0400 Subject: [PATCH 4/4] Add some hand-wavy language about forwards compat --- active/0000-homogeneous-tuples.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/active/0000-homogeneous-tuples.md b/active/0000-homogeneous-tuples.md index 441fd66d037..5b5d82c746c 100644 --- a/active/0000-homogeneous-tuples.md +++ b/active/0000-homogeneous-tuples.md @@ -74,7 +74,11 @@ None of which I am aware. precisely, `(T_1, ..., T_n)` would be a subtype of `[U, ..n]` if `forall i. T_i <: U`. This is elegant but would be a deeper change for something that rarely comes up in practice. I am not sure of - the full repercussions. + the full repercussions. I also don't think there's a big impact + betwee this proposal and that one -- that is, if we added + subtyping, these traits would presumably have little purpose, but + we could just stop including them in the prelude and/or adapt + somehow. 2. As above, but use coercion. This is actually a somewhat smaller change though I am reluctant to do anything but tighten coercion