Is there a reason why

    isOutputRange(R,E)

takes a second argument `E` but not other range predicates

    isInputRange(R)
    isForwardRange(R)
    ...

?

If so, I still think it would very be nice to have a second argument `E` for all the other `isXRange` traits to simplify, for instance,

    if (isInputRange!R && is(int == ElementType!R))

to simpler

    if (isInputRange!(R, int))

or even

    if (isInputRange!R && is(isSomeChar!(ElementType!R)))

to simpler

    if (isInputRange!(R, isSomeChar))

?

What do think?

I'm planning to add a PR for this and simplify Phobos in all places where this pattern is used.

On Monday, 2 November 2015 at 14:16:53 UTC, Nordlöw wrote:
> Is there a reason why
>
>     isOutputRange(R,E)
>
> takes a second argument `E` but not other range predicates
>
>     isInputRange(R)
>     isForwardRange(R)
>     ...
>
> ?
>
> If so, I still think it would very be nice to have a second argument `E` for all the other `isXRange` traits to simplify, for instance,
>
>     if (isInputRange!R && is(int == ElementType!R))
>
> to simpler
>
>     if (isInputRange!(R, int))
>
> or even
>
>     if (isInputRange!R && is(isSomeChar!(ElementType!R)))
>
> to simpler
>
>     if (isInputRange!(R, isSomeChar))
>
> ?
>
> What do think?
>
> I'm planning to add a PR for this and simplify Phobos in all places where this pattern is used.

https://github.com/D-Programming-Language/phobos/pull/3786

Atila

On Monday, 2 November 2015 at 14:16:53 UTC, Nordlöw wrote:
> Is there a reason why
>
>     isOutputRange(R,E)
>
> takes a second argument `E` but not other range predicates
>
>     isInputRange(R)
>     isForwardRange(R)
>     ...
>
> ?
>
> If so, I still think it would very be nice to have a second argument `E` for all the other `isXRange` traits to simplify, for instance,
>
>     if (isInputRange!R && is(int == ElementType!R))
>
> to simpler
>
>     if (isInputRange!(R, int))
>
> or even
>
>     if (isInputRange!R && is(isSomeChar!(ElementType!R)))
>
> to simpler
>
>     if (isInputRange!(R, isSomeChar))
>
> ?
>
> What do think?
>
> I'm planning to add a PR for this and simplify Phobos in all places where this pattern is used.

I think it's because output ranges can accept more than one type of value. That said, the `isInputRange!(R,E)` shortcut for `isInputRange!R && is(int == ElementType!R)` would be nice.

> https://github.com/D-Programming-Language/phobos/pull/3786

Sent an ICBM its way. -- Andrei

On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu wrote:
>> https://github.com/D-Programming-Language/phobos/pull/3786
>
> Sent an ICBM its way. -- Andrei

Why not extend existing traits with a second `E`-parameter instead of adding a new one?

On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
> On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu wrote:
>>> https://github.com/D-Programming-Language/phobos/pull/3786
>>
>> Sent an ICBM its way. -- Andrei
>
> Why not extend existing traits with a second `E`-parameter instead of adding a new one?

I think it's very well worth it in terms of expressability.

On 11/02/2015 09:43 AM, Nordlöw wrote:
> On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
>> On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu wrote:
>>>> https://github.com/D-Programming-Language/phobos/pull/3786
>>>
>>> Sent an ICBM its way. -- Andrei
>>
>> Why not extend existing traits with a second `E`-parameter instead of
>> adding a new one?
>
> I think it's very well worth it in terms of expressability.

I'd say it's a minor convenience. Anyhow, integrating tests this way depends on how we go about reporting "no match" errors. In the constraint

isForwardRange!R && is(ElementType!R == int)

the compiler could report exactly: "isForwardRange!Widget failed" or "is(ElementType!Widget == int) failed". If tests are combined, the compiler will only be able to say "isForwardRange!(Widget, int) failed".


Andrei

On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu wrote:
>> https://github.com/D-Programming-Language/phobos/pull/3786
>
> Sent an ICBM its way. -- Andrei

I agree with the ICBM that it definitely doesn't scale. But... there should be an easier way to replace arrays of Widget with a range. If not, most people (including me on lazy days) will just write `Widget[]` and be done with it. I don't know what the best solution is.

I'm saying this as someone who's written plenty of D code that takes arrays as arguments not because it's right, but because it was a lot easier and I didn't want it getting in the way of whatever it is I was trying to accomplish.. 90% of my usage of `std.array.array` is depressingly enough at the end of an algorithm UFCS chain because either I'm passing this to a function expecting `T[]` or to a struct that stores `T[]`. It's not pretty, performant, or right, but it's easy and I'm lazy.

And that's for writing code. With regards to reading, it's been pointed out multiple times that beginners will struggle with template contraints on function signatures. It'll be the case much more often if every function and struct wanting a range of Ts is suddenly `if(isInputRange!R && is(ElementType!R == T))`.

Atila

On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
> Why not extend existing traits with a second `E`-parameter instead of adding a new one?

What will E be when you only care whether R is an InputRange and not about its ElementType?

On Tuesday, 3 November 2015 at 01:36:31 UTC, Sebastiaan Koppe wrote:
> On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
>> Why not extend existing traits with a second `E`-parameter instead of adding a new one?
>
> What will E be when you only care whether R is an InputRange and not about its ElementType?

I think that the idea was that we'd keep isInputRange as-is (in which case, if you don't care about the element type, then you use that), and then we'd add an overload of isInputRange which took two arguments where the second argument is the ElementType.

- Jonathan M Davis