Since the compiler has the ability to detect input ranges in the foreach aggregate that are aggregates implementing the right primitives, why don't you set the widely used std.range.isInputRange as a __trait, e.g __traits(isInputRange, Stuff) ?

07.10.2017 13:31, user1234 пишет:
> Since the compiler has the ability to detect input ranges in the foreach aggregate that are aggregates implementing the right primitives, why don't you set the widely used std.range.isInputRange as a __trait, e.g __traits(isInputRange, Stuff) ?

IIRC the reason is if something could be done in library it should be done in library. Just to avoid making compiler more complex than it's necessary.
As for me isInputRange!Stuff is better than __traits(isInputRange, Stuff).

On Saturday, 7 October 2017 at 10:31:01 UTC, user1234 wrote:
> Since the compiler has the ability to detect input ranges in the foreach aggregate that are aggregates implementing the right primitives, why don't you set the widely used std.range.isInputRange as a __trait, e.g __traits(isInputRange, Stuff) ?

Because the __traits expression is supposed to be a fallback in place of where std.traits cannot be used, and should see minimum use.

On Saturday, 7 October 2017 at 10:36:21 UTC, drug wrote:
> 07.10.2017 13:31, user1234 пишет:
>> Since the compiler has the ability to detect input ranges in the foreach aggregate that are aggregates implementing the right primitives, why don't you set the widely used std.range.isInputRange as a __trait, e.g __traits(isInputRange, Stuff) ?
>
> IIRC the reason is if something could be done in library it should be done in library. Just to avoid making compiler more complex than it's necessary.

The point is that it's **already** in the compiler and that it could save hundreds of template instantiation.

> As for me isInputRange!Stuff is better than __traits(isInputRange, Stuff).

Yeah of course, for code cosmetic it could be wrapped in an templatized enum

enum isInputRange(T) = __traits(isInputRangeInternal, T);

On Saturday, October 07, 2017 10:31:01 user1234 via Digitalmars-d wrote:
> Since the compiler has the ability to detect input ranges in the foreach aggregate that are aggregates implementing the right primitives, why don't you set the widely used std.range.isInputRange as a __trait, e.g __traits(isInputRange, Stuff) ?

Why? What would we gain from that?

In general, the idea has been to do as little as possible with __traits and as much as possible in the library. And in theory, it was more or less the idea that std.traits would wrap __traits such that you'd never actually use __traits directly, but that's never quite happened.

- Jonathan M Davis

On Saturday, 7 October 2017 at 10:40:16 UTC, Jonathan M Davis wrote:
> On Saturday, October 07, 2017 10:31:01 user1234 via Digitalmars-d wrote:
>> Since the compiler has the ability to detect input ranges in the foreach aggregate that are aggregates implementing the right primitives, why don't you set the widely used std.range.isInputRange as a __trait, e.g __traits(isInputRange, Stuff) ?
>
> Why? What would we gain from that?

I've replied in another answer, so again, the idea is to save a bit of time spent to compile.

On Saturday, October 07, 2017 10:46:05 user1234 via Digitalmars-d wrote:
> On Saturday, 7 October 2017 at 10:40:16 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, October 07, 2017 10:31:01 user1234 via
> >
> > Digitalmars-d wrote:
> >> Since the compiler has the ability to detect input ranges in the foreach aggregate that are aggregates implementing the right primitives, why don't you set the widely used std.range.isInputRange as a __trait, e.g __traits(isInputRange, Stuff) ?
> >
> > Why? What would we gain from that?
>
> I've replied in another answer, so again, the idea is to save a bit of time spent to compile.

I very much doubt Walter would consider that a good enough reason. And it would make more sense to try and improve template processing in general than to try and speed things up by avoiding one template. In general, __traits does stuff that you can't check with a library, and we _can_ check in the case of isInputRange. At this point, if something can be done in a library, it's almost a guarantee that it won't be added to the language. A _really_ strong argument is needed for why something should be in the language rather than a library if it can be done in a library with the language as-is.

- Jonathan M Davis

On Saturday, 7 October 2017 at 10:59:02 UTC, Jonathan M Davis wrote:
> On Saturday, October 07, 2017 10:46:05 user1234 via
>> > Why? What would we gain from that?
>>
>> I've replied in another answer, so again, the idea is to save a bit of time spent to compile.
>
> I very much doubt Walter would consider that a good enough reason. And it would make more sense to try and improve template processing in general than to try and speed things up by avoiding one template. In general, __traits does stuff that you can't check with a library, and we _can_ check in the case of isInputRange. At this point, if something can be done in a library, it's almost a guarantee that it won't be added to the language. A _really_ strong argument is needed for why something should be in the language rather than a library if it can be done in a library with the language as-is.
>
> - Jonathan M Davis

Yes i understand the reasoning but the compiler has **already** the ability to check input ranges. For now it's just for aggregates (and even those who are input ranges by their alias this).