I'd like to clarify some conflicts I've encountered.

TDPL talks about ranges, it mentions random access ranges requiring these functions:

  T at(int i)
  Range slice(int x, int y)

But most code I encounter rather implements:

  T opIndex(size_t i)
  Range opSlice(size_t x, size_t y)

Which is it? Is there a distinction? One approach is deprecated?


Also, forward ranges require:

  Range save()

But there is also this function:

  Range opSlice()

With no args, handles the syntax 'range[]'. save() and opSlice() with no
args would appear to be identical.
Why have both? Which will be used in which cases?



On 24 March 2013 13:03, Manu <turkeyman@gmail.com> 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.
>

On Sunday, March 24, 2013 13:55:26 Manu wrote:
> I'd like to clarify some conflicts I've encountered.
> 
> TDPL talks about ranges, it mentions random access ranges requiring these functions:
> 
>   T at(int i)
>   Range slice(int x, int y)

This is not used by Phobos. I don't know why TDPL uses those. They are not supported at all and AFAIK never have been.

> Also, forward ranges require:
> 
>   Range save()
> 
> But there is also this function:
> 
>   Range opSlice()
> 
> With no args, handles the syntax 'range[]'. save() and opSlice() with no
> args would appear to be identical.
> Why have both? Which will be used in which cases?

Range opSlice()

is never used by ranges. It's only used by containers when you want to get a range for them.

If you want to know exactly which functions are supported by ranges, and the documentation isn't clear enough, just look at the definitions for the range traits in std.range - isInputRange, isForwardRange, etc. They specify exactly what a type must do to qualify as each type of range.

- Jonathan M Davis

On 24 March 2013 14:06, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, March 24, 2013 13:55:26 Manu wrote:
> > I'd like to clarify some conflicts I've encountered.
> >
> > TDPL talks about ranges, it mentions random access ranges requiring these functions:
> >
> >   T at(int i)
> >   Range slice(int x, int y)
>
> This is not used by Phobos. I don't know why TDPL uses those. They are not supported at all and AFAIK never have been.
>

My mistake; I stumbled upon an article written in 'CDJ#++', which I thought was an exert from TDPL (mixed my browser tabs up) >_<

> Also, forward ranges require:
> >
> >   Range save()
> >
> > But there is also this function:
> >
> >   Range opSlice()
> >
> > With no args, handles the syntax 'range[]'. save() and opSlice() with no
> > args would appear to be identical.
> > Why have both? Which will be used in which cases?
>
> Range opSlice()
>
> is never used by ranges. It's only used by containers when you want to get
> a
> range for them.
>

So what's the difference between save() and opSlice() though? They appear
to be identical regardless... is save() redundant?


If you want to know exactly which functions are supported by ranges, and the
> documentation isn't clear enough


This is my point, _there is no documentation_.



> just look at the definitions for the range
> traits in std.range - isInputRange, isForwardRange, etc. They specify
> exactly
> what a type must do to qualify as each type of range.
>

I have been, but since I'm just digging, and have
no authoritative reference, I am easily confused when I see conflicting or
apparently redundant code.
A D user shouldn't have to do this. I encourage a section under Language ->
Language Reference on dlang.org, to anyone who is an authority on the topic.

On Sunday, March 24, 2013 14:31:44 Manu wrote:
> So what's the difference between save() and opSlice() though? They appear
> to be identical regardless... is save() redundant?

Like I said, opSlice with no arguments is the function used on containers to
get a range for that container. It's never defined on ranges, and even if
someone were to define it on one of their ranges, it wouldn't be used except in
code they wrote which used. save is the function which is used to copy a
range, and it's required for a range to be considered a forward range.
Theoretically, opSlice with no arguments could have been reused for that, but
it wasn't.

> A D user shouldn't have to do this. I encourage a section under Language -> Language Reference on dlang.org, to anyone who is an authority on the topic.

Yes. We need a good article on ranges. I keep meaning to write one but haven't gotten around to it (and if anyone else has been planning on it, they haven't written it yet either). In the meantime, I suggest that you read the chapter on ranges in Ali Çehreli's book:

http://ddili.org/ders/d.en/ranges.html

There's also Walter's article on component programming which does a good job of explaining some of the motivation behind ranges and some good uses for them but doesn't really go into detail on their exact API beyond what's necessary in order to get his point across:

http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321

- Jonathan M Davis

That's why I think concepts are a good thing.
Container == vTable less Interfaces.
secure + documentation for free

On Sunday, 24 March 2013 at 03:55:35 UTC, Manu wrote:
> I'd like to clarify some conflicts I've encountered.
>
> TDPL talks about ranges, it mentions random access ranges requiring these
> functions:
>
>   T at(int i)
>   Range slice(int x, int y)
>
> But most code I encounter rather implements:
>
>   T opIndex(size_t i)
>   Range opSlice(size_t x, size_t y)
>
> Which is it? Is there a distinction? One approach is deprecated?
>
>
> Also, forward ranges require:
>
>   Range save()
>
> But there is also this function:
>
>   Range opSlice()
>
> With no args, handles the syntax 'range[]'. save() and opSlice() with no
> args would appear to be identical.
> Why have both? Which will be used in which cases?
>
>
>
> On 24 March 2013 13:03, Manu <turkeyman@gmail.com> 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.

Sorry meant Concept == vTable less Interface
On Sunday, 24 March 2013 at 06:20:14 UTC, bls wrote:
> That's why I think concepts are a good thing.
> Container == vTable less Interfaces.
> secure + documentation for free
>
> On Sunday, 24 March 2013 at 03:55:35 UTC, Manu wrote:
>> I'd like to clarify some conflicts I've encountered.
>>
>> TDPL talks about ranges, it mentions random access ranges requiring these
>> functions:
>>
>>  T at(int i)
>>  Range slice(int x, int y)
>>
>> But most code I encounter rather implements:
>>
>>  T opIndex(size_t i)
>>  Range opSlice(size_t x, size_t y)
>>
>> Which is it? Is there a distinction? One approach is deprecated?
>>
>>
>> Also, forward ranges require:
>>
>>  Range save()
>>
>> But there is also this function:
>>
>>  Range opSlice()
>>
>> With no args, handles the syntax 'range[]'. save() and opSlice() with no
>> args would appear to be identical.
>> Why have both? Which will be used in which cases?
>>
>>
>>
>> On 24 March 2013 13:03, Manu <turkeyman@gmail.com> 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.

24-Mar-2013 08:42, Jonathan M Davis пишет:
> On Sunday, March 24, 2013 14:31:44 Manu wrote:
>> So what's the difference between save() and opSlice() though? They appear
>> to be identical regardless... is save() redundant?
>
> Like I said, opSlice with no arguments is the function used on containers to
> get a range for that container. It's never defined on ranges, and even if
> someone were to define it on one of their ranges, it wouldn't be used except in
> code they wrote which used. save is the function which is used to copy a
> range, and it's required for a range to be considered a forward range.
> Theoretically, opSlice with no arguments could have been reused for that, but
> it wasn't.

There is no problem in random access range that has opSlice() to return itself. In fact, I'd expect it to always be range[0..$].

>
>> A D user shouldn't have to do this. I encourage a section under Language ->
>> Language Reference on dlang.org, to anyone who is an authority on the topic.
>
> Yes. We need a good article on ranges. I keep meaning to write one but haven't
> gotten around to it (and if anyone else has been planning on it, they haven't
> written it yet either). In the meantime, I suggest that you read the chapter
> on ranges in Ali Çehreli's book:
>
> http://ddili.org/ders/d.en/ranges.html
>
> There's also Walter's article on component programming which does a good job
> of explaining some of the motivation behind ranges and some good uses for them
> but doesn't really go into detail on their exact API beyond what's necessary
> in order to get his point across:
>
> http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321
>
> - Jonathan M Davis
>


-- 
Dmitry Olshansky

On Sunday, March 24, 2013 14:01:00 Dmitry Olshansky wrote:
> 24-Mar-2013 08:42, Jonathan M Davis пишет:
> > On Sunday, March 24, 2013 14:31:44 Manu wrote:
> >> So what's the difference between save() and opSlice() though? They appear
> >> to be identical regardless... is save() redundant?
> > 
> > Like I said, opSlice with no arguments is the function used on containers to get a range for that container. It's never defined on ranges, and even if someone were to define it on one of their ranges, it wouldn't be used except in code they wrote which used. save is the function which is used to copy a range, and it's required for a range to be considered a forward range. Theoretically, opSlice with no arguments could have been reused for that, but it wasn't.
> 
> There is no problem in random access range that has opSlice() to return itself. In fact, I'd expect it to always be range[0..$].

Of course, a range could implement the overload of opSlice without parameters, but it's not part of the standard range API, so you can't rely on it working for any type of range, and no range-based functions will used it, or if they do, they won't be compatible with normal ranges.

- Jonathan M Davis

24-Mar-2013 14:40, Jonathan M Davis пишет:
> On Sunday, March 24, 2013 14:01:00 Dmitry Olshansky wrote:
>> 24-Mar-2013 08:42, Jonathan M Davis пишет:
>>> On Sunday, March 24, 2013 14:31:44 Manu wrote:
>>>> So what's the difference between save() and opSlice() though? They appear
>>>> to be identical regardless... is save() redundant?
>>>
>>> Like I said, opSlice with no arguments is the function used on containers
>>> to get a range for that container. It's never defined on ranges, and even
>>> if someone were to define it on one of their ranges, it wouldn't be used
>>> except in code they wrote which used. save is the function which is used
>>> to copy a range, and it's required for a range to be considered a forward
>>> range. Theoretically, opSlice with no arguments could have been reused
>>> for that, but it wasn't.
>>
>> There is no problem in random access range that has opSlice() to return
>> itself. In fact, I'd expect it to always be range[0..$].
>
> Of course, a range could implement the overload of opSlice without parameters,
> but it's not part of the standard range API, so you can't rely on it working
> for any type of range, and no range-based functions will used it, or if they
> do, they won't be compatible with normal ranges.
>

Seems along the same lines as opDollar i.e. an addition that was overlooked and now hard to fit into requirements (because that'll break code).

> - Jonathan M Davis
>


-- 
Dmitry Olshansky

On Sunday, March 24, 2013 14:47:21 Dmitry Olshansky wrote:
> 24-Mar-2013 14:40, Jonathan M Davis пишет:
> > On Sunday, March 24, 2013 14:01:00 Dmitry Olshansky wrote:
> >> 24-Mar-2013 08:42, Jonathan M Davis пишет:
> >>> On Sunday, March 24, 2013 14:31:44 Manu wrote:
> >>>> So what's the difference between save() and opSlice() though? They
> >>>> appear
> >>>> to be identical regardless... is save() redundant?
> >>> 
> >>> Like I said, opSlice with no arguments is the function used on
> >>> containers
> >>> to get a range for that container. It's never defined on ranges, and
> >>> even
> >>> if someone were to define it on one of their ranges, it wouldn't be used
> >>> except in code they wrote which used. save is the function which is used
> >>> to copy a range, and it's required for a range to be considered a
> >>> forward
> >>> range. Theoretically, opSlice with no arguments could have been reused
> >>> for that, but it wasn't.
> >> 
> >> There is no problem in random access range that has opSlice() to return itself. In fact, I'd expect it to always be range[0..$].
> > 
> > Of course, a range could implement the overload of opSlice without parameters, but it's not part of the standard range API, so you can't rely on it working for any type of range, and no range-based functions will used it, or if they do, they won't be compatible with normal ranges.
> 
> Seems along the same lines as opDollar i.e. an addition that was overlooked and now hard to fit into requirements (because that'll break code).

Yeah, though implementing opSlice without any arguments wouldn't be particularly useful IMHO. Presumably, it would be the same as save, in which case, all you're doing is saving two characters. Maybe it should have been used instead of save, but it's far too late for that now.

- Jonathan M Davis