www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - isInputRange as a __traits ?

reply 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) ?
Oct 07
next sibling parent reply 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).
Oct 07
parent 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);
Oct 07
prev sibling next sibling parent 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.
Oct 07
prev sibling parent reply 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
Oct 07
parent reply 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.
Oct 07
parent reply 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
Oct 07
parent 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).
Oct 07