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

On Tuesday, 3 November 2015 at 03:26:47 UTC, Jonathan M Davis wrote:
> 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.

Am I the only one who ever writes `int[]` or `Struct[]` in a function signature?

Atila

On Tuesday, 3 November 2015 at 08:37:22 UTC, Atila Neves wrote:
> Am I the only one who ever writes `int[]` or `Struct[]` in a function signature?

Probably not, but I write very little code that operates on arrays rather than ranges. If I do, it's usually in a short program or script where I'm doing something that I don't intend to ever reuse, and there's no point in making it generic.

- Jonathan M Davis

On Monday, 2 November 2015 at 15:33:54 UTC, Atila Neves wrote:
> 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

I totally agree with you Atila. The whole point of this addition is not to find an alternative way of restricting templates for all you already skilled D developers that comment on this thread but instead:

*to make D easier to assimilate for beginners*

so we can achieve, according Andrei, our most important goal - grow by two orders of magnitude...that's why I believe these things really matter.

On Tuesday, 3 November 2015 at 10:08:04 UTC, Jonathan M Davis wrote:
> On Tuesday, 3 November 2015 at 08:37:22 UTC, Atila Neves wrote:
>> Am I the only one who ever writes `int[]` or `Struct[]` in a function signature?
>
> Probably not, but I write very little code that operates on arrays rather than ranges. If I do, it's usually in a short program or script where I'm doing something that I don't intend to ever reuse, and there's no point in making it generic.
>
> - Jonathan M Davis

I'd _like_ to write functions that take ranges instead; that's why I want to make it easier to declare "this parameter is an input range of T".

Atila

On Wednesday, 4 November 2015 at 10:37:54 UTC, Atila Neves wrote:
> On Tuesday, 3 November 2015 at 10:08:04 UTC, Jonathan M Davis wrote:
>> On Tuesday, 3 November 2015 at 08:37:22 UTC, Atila Neves wrote:
>>> Am I the only one who ever writes `int[]` or `Struct[]` in a function signature?
>>
>> Probably not, but I write very little code that operates on arrays rather than ranges. If I do, it's usually in a short program or script where I'm doing something that I don't intend to ever reuse, and there's no point in making it generic.
>>
>> - Jonathan M Davis
>
> I'd _like_ to write functions that take ranges instead; that's why I want to make it easier to declare "this parameter is an input range of T".

I confess that I don't find is(ElementType!E == Foo) to be particularly onerous. If that's what I need, then I do it and move on. It takes less time to write than this post, and it's not that uncommon that far more complicated conditions are required for template constraints anyway.

So, while I can understand why you'd want it to be simpler, it really doesn't seem like a big deal to me. And for that matter, if you really do want it to be simpler, there's nothing stopping you from creating your own traits to test with rather than just those in Phobos. It just means that it's not something that's going to be commonly used.

IMHO, if anything is annoying about writing template constraints, it's dealing with several overloads, since that frequently requires that you essentially put the negation of each overload in the other overloads.

- Jonathan M Davis