• user1234 (5/5) Oct 07 2017 Since the compiler has the ability to detect input ranges in the
• drug (5/9) Oct 07 2017 IIRC the reason is if something could be done in library it should be
• user1234 (6/17) Oct 07 2017 The point is that it's **already** in the compiler and that it
• Computermatronic (4/9) Oct 07 2017 Because the __traits expression is supposed to be a fallback in
• Jonathan M Davis (7/12) Oct 07 2017 Why? What would we gain from that?
• user1234 (4/12) Oct 07 2017 I've replied in another answer, so again, the idea is to save a
• Jonathan M Davis (10/24) Oct 07 2017 I very much doubt Walter would consider that a good enough reason. And i...
• user1234 (6/22) Oct 07 2017 Yes i understand the reasoning but the compiler has **already**

user1234 <user1234 12.ie> writes:

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) ?

drug <drug2004 bk.ru> writes:

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).

user1234 <user1234 12.ie> writes:

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);

Computermatronic <computermatronic gmail.com> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

user1234 <user1234 12.ie> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

user1234 <user1234 12.ie> writes:

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).