From c10f8e580fdd2a946d7148ec7de41957ff64b384 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Wed, 21 Jan 2015 23:05:39 +0100 Subject: [PATCH 1/3] RFC: Syntax for FullRange: `..` --- text/0000-fullrange-expression.md | 57 +++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 text/0000-fullrange-expression.md diff --git a/text/0000-fullrange-expression.md b/text/0000-fullrange-expression.md new file mode 100644 index 00000000000..3f544ef2336 --- /dev/null +++ b/text/0000-fullrange-expression.md @@ -0,0 +1,57 @@ +- Start Date: 2015-01-21 +- RFC PR: +- Rust Issue: + +# Summary + +Add the syntax `..` for `std::ops::FullRange`. + +# Motivation + +Range expressions `a..b`, `a..` and `..b` all have dedicated syntax and +produce first-class values. This means that they will be usable and +useful in custom APIs, so for consistency, the fourth slicing range, +`FullRange`, could have its own syntax `..` + +# Detailed design + +`..` will produce a `std::ops::FullRange` value when it is used in an +expression. This means that slicing the whole range of a sliceable +container is written `&foo[..]`. + +We should remove the old `&foo[]` syntax for consistency. Because of +this breaking change, it would be best to change this before Rust 1.0. + +As previously stated, when we have range expressions in the language, +they become convenient to use when stating ranges in an API. + +@Gankro fielded ideas where +methods like for example `.remove(index) -> element` on a collection +could be generalized by accepting either indices or ranges. Today's `.drain()` +could be expressed as `.remove(..)`. + +Matrix or multidimensional array APIs can use the range expressions for +indexing and/or generalized slicing and `..` represents selecting a full axis +in a multidimensional slice, i.e. `(1..3, ..)` slices the first axis and +preserves the second. + +Because of deref coercions, the very common conversions of String or Vec to +slices don't need to use slicing syntax at all, so the change in verbosity from +`[]` to `[..]` is not a concern. + +# Drawbacks + +Removing the slicing syntax `&foo[]` is a breaking change. + +# Alternatives + +* We could add this syntax later, but we would end up with duplicate + slicing functionality using `&foo[]` and `&foo[..]`. + +* `0..` could replace `..` in many use cases (but not for ranges in + ordered maps). + +# Unresolved questions + +Any parsing questions should already be mostly solved because of the +`a..` and `..b` cases. From ff6c314ba019de28ac41d5daa186b940c6254719 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Fri, 30 Jan 2015 21:30:08 +0100 Subject: [PATCH 2/3] Update for rename to RangeFull --- ...fullrange-expression.md => 0000-rangefull-expression.md} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename text/{0000-fullrange-expression.md => 0000-rangefull-expression.md} (91%) diff --git a/text/0000-fullrange-expression.md b/text/0000-rangefull-expression.md similarity index 91% rename from text/0000-fullrange-expression.md rename to text/0000-rangefull-expression.md index 3f544ef2336..f58419297d3 100644 --- a/text/0000-fullrange-expression.md +++ b/text/0000-rangefull-expression.md @@ -4,18 +4,18 @@ # Summary -Add the syntax `..` for `std::ops::FullRange`. +Add the syntax `..` for `std::ops::RangeFull`. # Motivation Range expressions `a..b`, `a..` and `..b` all have dedicated syntax and produce first-class values. This means that they will be usable and useful in custom APIs, so for consistency, the fourth slicing range, -`FullRange`, could have its own syntax `..` +`RangeFull`, could have its own syntax `..` # Detailed design -`..` will produce a `std::ops::FullRange` value when it is used in an +`..` will produce a `std::ops::RangeFull` value when it is used in an expression. This means that slicing the whole range of a sliceable container is written `&foo[..]`. From 25d35f1f9d842dfdc5b49e9777ea4ad817659b94 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Fri, 30 Jan 2015 21:35:18 +0100 Subject: [PATCH 3/3] Mention the drawback/overlap with .. in patterns --- text/0000-rangefull-expression.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/text/0000-rangefull-expression.md b/text/0000-rangefull-expression.md index f58419297d3..f2a59541912 100644 --- a/text/0000-rangefull-expression.md +++ b/text/0000-rangefull-expression.md @@ -41,7 +41,11 @@ slices don't need to use slicing syntax at all, so the change in verbosity from # Drawbacks -Removing the slicing syntax `&foo[]` is a breaking change. +* Removing the slicing syntax `&foo[]` is a breaking change. + +* `..` already appears in patterns, as in this example: + `if let Some(..) = foo { }`. This is not a conflict per se, but the + same syntax element is used in two different ways in Rust. # Alternatives