Technically, prior to this change, it was possible to define popFront
and popBack to be callables that required parens - such as member
variable with an overloaded opCall or a delegate. It's unlikely that
anyone has actually declared popFront or popBack in this manner, but
it's possible. Because of that, calling popFront or popBack without
parens would technically not work with some valid ranges (even if such
ranges are unlikely to exist) and thus without this change, it's
arguably not valid to call popFront or popBack without parens in generic
code - especially in the standard library.
Andrei wants to be able to call popFront without parens in generic code,
and when I pointed out the existing problem with that, he wanted me to
change it so that it's no longer legal to have a range where popFront or
popBack is a callable that requires parens. So, this PR fixes that.
Now, technically, this is a breaking change, but it's highly unlikely
that it actually breaks any code, and I don't know of any way to do this
change in a way which would allow for any kind of deprecation message
for anyone trying to declare a range with a popFront or popBack that
would not work without parens. So, as far as I can tell, if we want to
make this change, we're stuck making a breaking change, but the odds of
it actually mattering seem low.
Replace following names:
std.typetuple -> std.meta
TypeTuple -> AliasSeq
ParameterTypeTuple -> Parameters
FieldTypeTuple -> Fields
std.traits requires more work than search/replace and is left unchanged.
Excluding the UTF-decoding variants, because those throw GC allocated
exceptions.
Makes sure that issue 12666 - "@nogc std.array.front, popFront, and more"
stays fixed.
The previous docs were simply dissected from the original std.range docs, and
the text in each module is truncated and awkward to read. The main package.d
docs were also missing links to the submodules. So, update the docs to reflect
the current state of things.
