www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Range documentation

reply Manu <turkeyman gmail.com> writes:
I'm trying to write some ranges with strictly controlled sets of features,
but the docs on ranges are either very poor, or illusive (I can't find any).

Suggest: Add a category under Language -> Language Reference about ranges,
and all the stuff that defines their use/limitations. With some examples.

I'm just copying from the std libs and hope I catch all the details.
Mar 23 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/23/2013 8:03 PM, Manu wrote:
 I'm trying to write some ranges with strictly controlled sets of features, but
 the docs on ranges are either very poor, or illusive (I can't find any).

 Suggest: Add a category under Language -> Language Reference about ranges, and
 all the stuff that defines their use/limitations. With some examples.

 I'm just copying from the std libs and hope I catch all the details.
I agree that the documentation on ranges is lame at best. At worst, it is incomprehensible without looking at the source code. This is unacceptable.
Mar 23 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 24 March 2013 at 05:12:49 UTC, Walter Bright wrote:
 On 3/23/2013 8:03 PM, Manu wrote:
 I'm trying to write some ranges with strictly controlled sets 
 of features, but
 the docs on ranges are either very poor, or illusive (I can't 
 find any).

 Suggest: Add a category under Language -> Language Reference 
 about ranges, and
 all the stuff that defines their use/limitations. With some 
 examples.

 I'm just copying from the std libs and hope I catch all the 
 details.
I agree that the documentation on ranges is lame at best. At worst, it is incomprehensible without looking at the source code. This is unacceptable.
I think the documentation is the reflect of the state of range. They have been made in an ad hoc manner, and many part are blurry. For instance, passing a range by value is unspecified.
Mar 24 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, March 24, 2013 09:42:28 deadalnix wrote:
 For instance, passing a range by value is unspecified.
And it never will be specified, because it's range-dependent and can't ever be anything but range-dependent. That's why save was introduced in the first place. If you want to guarantee that a range is consumed, you make sure that the range-based function that you're passing the range to takes it by ref. If you want to guarantee that it's not consumed, then you call save and pass its result to the range-based function. Beyond that, you have to write your code in a way in which it doesn't matter whether the range is consumed or not when it's passed to a function, because that depends on the type of the range. There's literally no technical way to avoid this except for 1. Require that all range-based functions take ranges by ref, which is not only unenforceable but would kill function chaining, which is one of the great strengths of ranges. 2. Require that all ranges be reference types, which again, is not enforceable, but also wouldn't work with ranges, because they're always sliced when you pass them to a function (and you couldn't require that all ranges be value types, because pure input ranges can never be value types). So, we're stuck. Sure, the fact that whether a range is consumed or not when passed to a function is effectively undefined is troublesome, but there's really no way around it. - Jonathan M Davis
Mar 24 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 24 March 2013 at 09:36:34 UTC, Jonathan M Davis wrote:
 On Sunday, March 24, 2013 09:42:28 deadalnix wrote:
 For instance, passing a range by value is unspecified.
And it never will be specified, because it's range-dependent and can't ever be anything but range-dependent. That's why save was introduced in the first place. If you want to guarantee that a range is consumed, you make sure that the range-based function that you're passing the range to takes it by ref. If you want to guarantee that it's not consumed, then you call save and pass its result to the range-based function. Beyond that, you have to write your code in a way in which it doesn't matter whether the range is consumed or not when it's passed to a function, because that depends on the type of the range. There's literally no technical way to avoid this except for 1. Require that all range-based functions take ranges by ref, which is not only unenforceable but would kill function chaining, which is one of the great strengths of ranges. 2. Require that all ranges be reference types, which again, is not enforceable, but also wouldn't work with ranges, because they're always sliced when you pass them to a function (and you couldn't require that all ranges be value types, because pure input ranges can never be value types). So, we're stuck. Sure, the fact that whether a range is consumed or not when passed to a function is effectively undefined is troublesome, but there's really no way around it.
Sure we are stuck, because fixing this would require a refinement of the range concept, and it is kind of too late for that. But you say that this inherently impossible without actually providing anything convincing in that direction. I don't think it is, I just think that as usual as hoc solutions are conglomerated in what is now ranges.
Mar 24 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, March 24, 2013 12:14:56 deadalnix wrote:
 Sure we are stuck, because fixing this would require a refinement
 of the range concept, and it is kind of too late for that.
 
 But you say that this inherently impossible without actually
 providing anything convincing in that direction. I don't think it
 is, I just think that as usual as hoc solutions are conglomerated
 in what is now ranges.
It's inherently impossible because the only way for it to be possible is to make it so that all ranges are reference types or so that all ranges are value types (that's the only way that copying them will always have the same semantics), and it's not possible for all ranges to be reference types or for all ranges to be value types. The very nature of a pure input range makes it a reference type, so we couldn't make all ranges value types, and the fact that arrays are always sliced when you pass them to a function makes it so that they can't be reference types. So, you can't make it so that all ranges are one or the other, and so you can't guarantee that copying them will always have the same behavior. Either we'd have to ditch pure input ranges (which actually wouldn't hurt my feelings any) or fundamentally change how arrays work (which probably be a bad idea) in order to make it so that all ranges are value types or so that all ranges are reference types. But the basic design of ranges precludes making it so that they're all one or the other. - Jonathan M Davis
Mar 24 2013