2.2 KiB
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.