Syntax for RangeFull: ..

text/0000-rangefull-expression.md

@@ -0,0 +1,61 @@
+- Start Date: 2015-01-21
+- RFC PR:
+- Rust Issue:
+
+# Summary
+
+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,
+`RangeFull`, could have its own syntax `..`
+
+# Detailed design
+
+`..` 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[..]`.
+
+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.
+
+* `..` 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
+
+* 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.