On 02/22/2017 06:53 AM, Atila Neves wrote:
On Thursday, 16 February 2017 at 13:21:04 UTC, Andrei Alexandrescu wrote:
On 2/16/17 7:11 AM, Atila Neves wrote:
On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote:
On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote:
Your documentation is an improvement but it doesn't help when reading
the source code.
Yeah, I think there's a few things we can do in the source too. We
should find the common combinations and abstract them out, like I said
before, isInputRangeOf is potentially useful.
Though, like Andrei, I'm skeptical on doing too much of that, since
the combinations can quickly explode and then you just have to search
through more to figure out wtf they mean.
That'd help the source and docs if we find the right balance.
I submitted a Phobos PR for `isInputRangeOf`. It was nuked from orbit. I
understand why: as you mention, the combinatorial explosion of names is
an issue. But: it's a mess rangeifying code when this:
void fun(Foo[] foos); // yay! readable
becomes:
void fun(R)(R foos) if(isInputRange!R && is(Unqual!(ElementType!R) ==
Foo);
If you find a number of these, that would be good evidence. -- Andrei
I found just over 70 similar lines, which is more than I expected given
how generic Phobos is. The real issue is in client code though. I write
less range-based code than I'd like, because it's a lot easier to make
it a regular array and change it later if the function needs to be
called with other ranges.
If you submit a pull request that simplifies >70 constraints in Phobos
and implicitly promises to simplify client-level constraints as much,
that would have a good chance to be accepted. Destroy! -- Andrei
