A Range is something that implements one or more interfaces depending on its properties and guarantees. So in order to name a Range that way you'd first have to create interfaces for all possible guarantees. That doesn't sound practical. It's analogous to C++ containers implementing common concepts without deriving from corresponding interfaces.

See also https://tour.dlang.org/tour/en/basics/ranges

Yes, this is what C++ concepts are supposed to solve: https://en.cppreference.com/w/cpp/language/constraints

In D, you don't declare that a type X should have operations A, B, C. Instead, at the moment of template instantiation, you can verify if the provided type has operations A, B and C.

That makes for terrible docs and discoverability, which is the problem here.

Maybe D should allow the user to name the return type (an existential variable) and static assert stuff on it:

`SomeVar f(…) with isRange!SomeVar` or whatever. `auto` just means "you have to read the implementation because it can be literally anything"

Well, it is visible in documentation, but even those can be hard to parse:

uint startsWith(alias pred = (a, b) => a == b, Range, Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range && (Needles.length > 1) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) : uint));

You did pick a particularly nasty example for that one. I do agree that it is not so easy to read these constraints. It can also be a bit frustrating when you need to chase down why exactly a particular line of code doesn't meet such a constraint. Tests like isInputRange are themselves fairly involved expressions and in the worst case, you end up staring at those after a template instantiation failed.

D's version of concepts have optional operations, it has been found to decrease the need for names