Add isInputRangeOf template constraint

[atilaneves]

Idiomatic D uses input ranges where possible. Right now however, transiotining a function from taking T[] to a range is more cumbersome than necessary. This PR introduces a new template contraint so that:

void func(int[] numbers) { /*...*/ }

Can easily be converted to

void func(R)(R range) if(isInputRangeOf!(R, int)) { /*...*/ }

Instead of manually typing out

void func(R)(R range) if(isInputRange!R && is(ElementType!R == int)) { /*...*/ }

[JackStouffer]

I understand that we want to make it as easy as possible for people to port their code to ranges, but I really don't see the value in this, especially since most of the time what you want is(ElementType!R : int). The only thing this gives you is saving about 20 keystrokes.

[atilaneves]

Usability should be a concern. void func(int[]) is easy to type and read. The equivalent range version is not. Fair point about convertibility though.

[JakobOvrum]

Actually, I think what you usually want is isIntegral!(ElementType!R). Similarly for string algorithms we almost always see isSomeChar!(ElementEncodingType!R).

Is it common for a range algorithm to require an input range of a specific type?

[atilaneves]

Maybe int and string are bad examples. This is supposed to aid replacing T[] with a range in function signatures and struct members. Let's consider instead MyStruct[] and taking a range instead.

Range algorithms don't usually care what the element type is. They're very generic.

[andralex]

This doesn't seem the be necessary. isOutputRange takes two parameters because output ranges accept more than one type (e.g. strings take both char and dchar etc). For input ranges, there's no such thing.

Also, testing the range capability is often orthogonal from testing the element type. Before long we'll have isForwardRangeOf, isBidirectionalRangeOf, etc. etc. etc. That doesn't scale.

Thanks for the work - I'll close this now. Please reopen if good arguments come about.

[nordlow]

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

See also: http://forum.dlang.org/post/hakctxoihemjnexknzqi@forum.dlang.org