• Manu (5/5) Mar 23 2013 I'm trying to write some ranges with strictly controlled sets of feature...
• Walter Bright (3/8) Mar 23 2013 I agree that the documentation on ranges is lame at best. At worst, it i...
• deadalnix (4/20) Mar 24 2013 I think the documentation is the reflect of the state of range.
• Jonathan M Davis (21/22) Mar 24 2013 And it never will be specified, because it's range-dependent and can't e...
• deadalnix (7/44) Mar 24 2013 Sure we are stuck, because fixing this would require a refinement
• Jonathan M Davis (16/23) Mar 24 2013 It's inherently impossible because the only way for it to be possible is...

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.

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.

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

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

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

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