Second CT-Parameter of isRange Predicates
Jonathan M Davis via Digitalmars-d
digitalmars-d at puremagic.com
Mon Nov 2 19:26:44 PST 2015
On Monday, 2 November 2015 at 15:00:23 UTC, Andrei Alexandrescu
> 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:
>>>> 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
More information about the Digitalmars-d