A while ago I fixed issue 5052, but doing so I unwittingly broke David's earlier fix for issue 4464.  I believe I have now fixed both issues (not committed to main Phobos repo yet):

https://github.com/kyllingstad/phobos/commit/3948e3f61403bd7618913c36959158018970011d

While fixing this, I noted that Take!R simply aliases to R when R is a type that supports slicing.  This assumes that the slice has the same type as the slicee(?), which doesn't have to be the case -- at least as far as the compiler or hasSlicing!() are concerned.

It is easy to fix in Take, but I've now discovered that the same assumption is made in a lot of places: Retro, Stride, Chain... the list goes on.  Just do a search for hasSlicing, or look for things like

    _input = _input[i .. j];

Fixing it everywhere is likely to be a lot of work.  Do you think it is worth it, or is this a tiny corner case?

-Lars

Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:

> A while ago I fixed issue 5052, but doing so I unwittingly broke David's earlier fix for issue 4464.  I believe I have now fixed both issues (not committed to main Phobos repo yet):
>
> https://github.com/kyllingstad/phobos/commit/3948e3f61403bd7618913c36959158018970011d
>
> While fixing this, I noted that Take!R simply aliases to R when R is a type that supports slicing.  This assumes that the slice has the same type as the slicee(?), which doesn't have to be the case -- at least as far as the compiler or hasSlicing!() are concerned.
>
> It is easy to fix in Take, but I've now discovered that the same assumption is made in a lot of places: Retro, Stride, Chain... the list goes on.  Just do a search for hasSlicing, or look for things like
>
>     _input = _input[i .. j];
>
> Fixing it everywhere is likely to be a lot of work.  Do you think it is worth it, or is this a tiny corner case?

IMO, ranges that support slicing should return their own type as a slice. I
believe this is always the case in existing ranges, and that it's a good
idea
in general.

-- 
Simen

On Wed, 2011-02-02 at 15:05 +0100, Simen Kjaeraas wrote:
> Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> 
> > A while ago I fixed issue 5052, but doing so I unwittingly broke David's earlier fix for issue 4464.  I believe I have now fixed both issues (not committed to main Phobos repo yet):
> >
> > https://github.com/kyllingstad/phobos/commit/3948e3f61403bd7618913c36959158018970011d
> >
> > While fixing this, I noted that Take!R simply aliases to R when R is a type that supports slicing.  This assumes that the slice has the same type as the slicee(?), which doesn't have to be the case -- at least as far as the compiler or hasSlicing!() are concerned.
> >
> > It is easy to fix in Take, but I've now discovered that the same assumption is made in a lot of places: Retro, Stride, Chain... the list goes on.  Just do a search for hasSlicing, or look for things like
> >
> >     _input = _input[i .. j];
> >
> > Fixing it everywhere is likely to be a lot of work.  Do you think it is worth it, or is this a tiny corner case?
> 
> IMO, ranges that support slicing should return their own type as a slice. I
> believe this is always the case in existing ranges, and that it's a good
> idea
> in general.

While I don't necessarily disagree with this idea, I would like to point out that there was, at one point, serious discussion about whether built-in array slices should be a separate type.  (Remember T[new]?)

-Lars

Yah, I've been cagey about this because I wasn't clear on what range would want to ever return a different type. Recently I realized that an infinite range with random access would want to actually define slicing to return a different type, for the simple reason that after slicing you have a finite range (which is, I'd guess, random access). I'm not sure how important that case is, so I suggest we hang loose until some more evidence comes about.

Andrei

On 2/2/11 6:54 AM, Lars Tandle Kyllingstad wrote:
> A while ago I fixed issue 5052, but doing so I unwittingly broke David's earlier fix for issue 4464.  I believe I have now fixed both issues (not committed to main Phobos repo yet):
>
> https://github.com/kyllingstad/phobos/commit/3948e3f61403bd7618913c36959158018970011d
>
> While fixing this, I noted that Take!R simply aliases to R when R is a type that supports slicing.  This assumes that the slice has the same type as the slicee(?), which doesn't have to be the case -- at least as far as the compiler or hasSlicing!() are concerned.
>
> It is easy to fix in Take, but I've now discovered that the same assumption is made in a lot of places: Retro, Stride, Chain... the list goes on.  Just do a search for hasSlicing, or look for things like
>
>      _input = _input[i .. j];
>
> Fixing it everywhere is likely to be a lot of work.  Do you think it is worth it, or is this a tiny corner case?
>
> -Lars
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 02/02/2011 03:05 PM, Simen Kjaeraas wrote:
> Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
>
>> A while ago I fixed issue 5052, but doing so I unwittingly broke David's earlier fix for issue 4464. I believe I have now fixed both issues (not committed to main Phobos repo yet):
>>
>> https://github.com/kyllingstad/phobos/commit/3948e3f61403bd7618913c36959158018970011d
>>
>>
>> While fixing this, I noted that Take!R simply aliases to R when R is a type that supports slicing. This assumes that the slice has the same type as the slicee(?), which doesn't have to be the case -- at least as far as the compiler or hasSlicing!() are concerned.
>>
>> It is easy to fix in Take, but I've now discovered that the same assumption is made in a lot of places: Retro, Stride, Chain... the list goes on. Just do a search for hasSlicing, or look for things like
>>
>> _input = _input[i .. j];
>>
>> Fixing it everywhere is likely to be a lot of work. Do you think it is worth it, or is this a tiny corner case?
>
> IMO, ranges that support slicing should return their own type as a slice. I believe this is always the case in existing ranges, and that it's a good idea in general.

I think so as well, matches slice semantics for arrays. Exceptional needs (?) may either be handled by specific funcs, or let as homework for client code ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com