They were marked for removal in the docs (many of them were intended to
be removed in January), so now they've been removed from the docs and
marked for removal from the code in November.
From: #1183 :
Issue 9612: Cycle opSlice should throw when finish > start
Because a RangeError is not actually customizable, and the first argument is actually the file name. The error was producing:
```
core.exception.RangeError@2 > 1(3836): Range violation
```
Now it produces:
```
core.exception.RangeError@std\range.d(3835): Range violation
```
Because returning anything other than an *exact* type match messes everything up. This is particularly true in the sense that "saved" ranges are usually passed directly to a function, so not cast back to the original.
Mainly, they accepted the types R, provided Unqual!R is a range. But that doesn't make sense.
Reduced to only accepting if R itself is a range.
Improved constraints, fixed implementations, removed needles bug workaround.
This adds range type `Only!T` and helper function `only!T(T)`. This is a range that iterates a single value, useful when some interface requires a range, but you only have a single value.
It now requires that indexing with $ result in the same type as front if
r[$] works, and if that works, and the range isn't infinite, r[$ - 1]
must be the same type as front. Ideally, we'd require that r[$] work
regardless, but without enhancement #7177 being implemented, that would
likely break too much code, as opDollar was only recently fixed and
probably isn't used much.
The extra requirements are not currently enabled because of bug# 8847,
but they're now there, and they're listed as their in the documentation
so that no one will think that they're not supposed to apply.
Ideally, opDollar would be outright required for any range with slicing,
but unless/until it's changed so that length automatically aliases to
opDollar when opDollar isn't defined (issue# 7177), that's probably not
a reasonable requirement to make.
Now, it enforces that opSlice returns a range which can be assigned to
the original range type (so that it can be assigned to the original
range as long as the original range isn't const) as long as it's finite,
and it enforces that opSlice's result is the result of take when the
range is infinite.
takeExactly now returns the same type as take where possible, and
neither take nor takeExactly check hasSlicing for infinite ranges (since
infinite ranges will soon be required to use them for slicing, and that
creates a circular dependency among those 3 templates
