I thought it was odd that inserting an element at the front of a singly-linked-list would be an O(log(n)) operation. Too expensive! So I looked at the code and it does seem to be O(1). I'm hoping this is just needing a documentation edit ;)
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.
import std.algorithm;
import std.range;
void main()
{
auto N2 = sequence!"n"(cast(size_t)1).map!"a";
}
ceased to compile, because Map's opSlice won't work anymore over
infinite ranges, because the result can't be reassigned to the original.
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
Previously endsWith constraints only required input ranges, but the algorithm uses `back` and `popBack` within, so clearly a bidirectional range is needed.
