Second CT-Parameter of isRange Predicates

[Jonathan M Davis via Digitalmars-d]

On Monday, 2 November 2015 at 15:00:23 UTC, Andrei Alexandrescu 
wrote:
> 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.

I'm actually a bit surprised at the suggestion, since I would 
have expected most code to either not care what the ElementType 
was or to have to test something about it other than simply 
testing for an exact type. And given how frequently Unqual needs 
to get involved with tests on ElementType, simply testing the 
exact type would likely be problematic for many of the common 
cases that would initially seem to benefit from having 
isInputRange!(R, E) as a shortcut. So, it might be nice to have 
in some cases, but in general, I don't think that it's expressive 
enough, and I don't like how it's not orthogonal to the existing 
traits, since it's really just combining two of them.

- Jonathan M Davis