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
This reverts commit 07104b5fe6.
As we cannot currenly rely on even ranges with slicing implementing
opDollar, this change breaks code, because it assumes that such ranges
implement opDollar.
- I assume they are not properties, then changed to normal functions.
- Global .moveFront/Back uses front and back if member moveFront/back doesn't exist.
Then, member aliases are just redundant.
I don't know why these were added or how they got past the reviewers,
but it makes no sense for traits which check ranges for various
attributes to say that they don't require a range - especially when they
specifically check stuff like front! The only two where such a comment
makes sense (hasLength and ElementType) already had such comments,
making the comments added to them redundant, whereas the others were
just plain wrong. This commit removes all of those incorrect comments.
