A whole bunch of stuff in Phobos (including std.range.Radial and the FFT algorithm I just checked in) requires that ranges provided to it have slicing.  This limitation is a PITA.  Should we add a Slicer meta-range that takes a finite random-access range and bolts slicing on in the obvious but relatively inefficient way if it's not already supported and simply returns the range if it already supports slicing?  This would be used under the hood when slicing is required.  For example:

struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {
     R range;
     size_t lowerLim, upperLim;

     this(R r) {
          this.range = range;
          this.upperLim = range.length;
     }

     // Range primitives:  front, popFront, etc.

     typeof(this) opSlice(size_t lower, size_t upper) {
         // Error checking
         auto ret = this;
         ret.upperLim -= this.length - upper;
         ret.lowerLim += lower;
         return ret;
     }
}

auto slicer(R)(R range) {
     static if(hasSlicing!R) {
         return range;
     } else {
          return Slicer!(R)(range);
     }
}

On Thursday, August 12, 2010 20:24:03 David Simcha wrote:
> A whole bunch of stuff in Phobos (including std.range.Radial and the FFT algorithm I just checked in) requires that ranges provided to it have slicing.  This limitation is a PITA.  Should we add a Slicer meta-range that takes a finite random-access range and bolts slicing on in the obvious but relatively inefficient way if it's not already supported and simply returns the range if it already supports slicing?  This would be used under the hood when slicing is required.  For example:
> 
> struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {
>      R range;
>      size_t lowerLim, upperLim;
> 
>      this(R r) {
>           this.range = range;
>           this.upperLim = range.length;
>      }
> 
>      // Range primitives:  front, popFront, etc.
> 
>      typeof(this) opSlice(size_t lower, size_t upper) {
>          // Error checking
>          auto ret = this;
>          ret.upperLim -= this.length - upper;
>          ret.lowerLim += lower;
>          return ret;
>      }
> }
> 
> auto slicer(R)(R range) {
>      static if(hasSlicing!R) {
>          return range;
>      } else {
>           return Slicer!(R)(range);
>      }
> }
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I'm not sure I like the idea that this would be done without programmer intervention. If it's inefficient, it'll lead to programmers using range types with algorithms that really aren't supposed to take those range types and without them realizing the fact that it's inefficient. Having a means to allow the programmer to wrap a range to allow it to be used by an algorithm which it wouldn't normally work with may be a good idea, but each algorithm takes certain types of ranges for a reason, and I'd hate to see much impact to efficiency because of internal range wrangling that the programmer using the function isn't even aware of.

- Jonathan M Davis

I would agree if we were talking about big-O efficiency, or even a large constant overhead, but IMHO avoiding Slicer is a micro-optimization, not a macro-optimization.  Therefore, by default it should "just work" even if it's slightly inefficient and intervention should be required only if the programmer decides it needs to be optimized.

On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis <jmdavisprog at gmail.com>wrote:

> On Thursday, August 12, 2010 20:24:03 David Simcha wrote:
> > A whole bunch of stuff in Phobos (including std.range.Radial and the FFT algorithm I just checked in) requires that ranges provided to it have slicing.  This limitation is a PITA.  Should we add a Slicer meta-range that takes a finite random-access range and bolts slicing on in the obvious but relatively inefficient way if it's not already supported and simply returns the range if it already supports slicing?  This would be used under the hood when slicing is required.  For example:
> >
> > struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {
> >      R range;
> >      size_t lowerLim, upperLim;
> >
> >      this(R r) {
> >           this.range = range;
> >           this.upperLim = range.length;
> >      }
> >
> >      // Range primitives:  front, popFront, etc.
> >
> >      typeof(this) opSlice(size_t lower, size_t upper) {
> >          // Error checking
> >          auto ret = this;
> >          ret.upperLim -= this.length - upper;
> >          ret.lowerLim += lower;
> >          return ret;
> >      }
> > }
> >
> > auto slicer(R)(R range) {
> >      static if(hasSlicing!R) {
> >          return range;
> >      } else {
> >           return Slicer!(R)(range);
> >      }
> > }
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
>
> I'm not sure I like the idea that this would be done without programmer
> intervention. If it's inefficient, it'll lead to programmers using range
> types
> with algorithms that really aren't supposed to take those range types and
> without them realizing the fact that it's inefficient. Having a means to
> allow the
> programmer to wrap a range to allow it to be used by an algorithm which it
> wouldn't normally work with may be a good idea, but each algorithm takes
> certain
> types of ranges for a reason, and I'd hate to see much impact to efficiency
> because of internal range wrangling that the programmer using the function
> isn't
> even aware of.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100813/efabea6b/attachment-0001.html>

On Friday, August 13, 2010 10:32:11 David Simcha wrote:
> I would agree if we were talking about big-O efficiency, or even a large constant overhead, but IMHO avoiding Slicer is a micro-optimization, not a macro-optimization.  Therefore, by default it should "just work" even if it's slightly inefficient and intervention should be required only if the programmer decides it needs to be optimized.

Well, if it's deemed that it's not a big difference, then I don't think that I really have a problem with it. It bugs me a bit still, but that doesn't mean that it's a bad idea. We definitely need std.algorithm to generally be efficient, but we also need it to be useable. So, if the cost in efficiency is small enough, and there really are a lot of ranges that have this problem, then Slicer probably should be used.

- Jonathan M Davis

IMHO (I'm 99.999% sure Andrei will disagree with me) if you really want to exploit every possible micro-optimization you shouldn't be using generic code in the first place.  The ability to write generic code that's as efficient as the equivalent hand-written code is a major achievement of templates.  However, if you know your data and use cases inside out and care about getting every last bit of performance, you won't write equivalent hand-written code, you'll write super micro-optimized hand-written code tailored to the data and use case.  There are almost always opportunities for ad-hoc micro-optimization, though whether they are worth implementing in any given case is a different question.

On Fri, Aug 13, 2010 at 2:00 PM, Jonathan M Davis <jmdavisprog at gmail.com>wrote:

> On Friday, August 13, 2010 10:32:11 David Simcha wrote:
> > I would agree if we were talking about big-O efficiency, or even a large constant overhead, but IMHO avoiding Slicer is a micro-optimization, not
> a
> > macro-optimization.  Therefore, by default it should "just work" even if it's slightly inefficient and intervention should be required only if the programmer decides it needs to be optimized.
>
> Well, if it's deemed that it's not a big difference, then I don't think
> that I
> really have a problem with it. It bugs me a bit still, but that doesn't
> mean
> that it's a bad idea. We definitely need std.algorithm to generally be
> efficient,
> but we also need it to be useable. So, if the cost in efficiency is small
> enough,
> and there really are a lot of ranges that have this problem, then Slicer
> probably should be used.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100813/b06ad834/attachment.html>

I'd favor simplicity by just requiring random-access ranges to define slicing.

Andrei

David Simcha wrote:
> I would agree if we were talking about big-O efficiency, or even a large constant overhead, but IMHO avoiding Slicer is a micro-optimization, not a macro-optimization.  Therefore, by default it should "just work" even if it's slightly inefficient and intervention should be required only if the programmer decides it needs to be optimized.
> 
> On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis <jmdavisprog at gmail.com <mailto:jmdavisprog at gmail.com>> wrote:
> 
>     On Thursday, August 12, 2010 20:24:03 David Simcha wrote:
>      > A whole bunch of stuff in Phobos (including std.range.Radial and
>     the FFT
>      > algorithm I just checked in) requires that ranges provided to it have
>      > slicing.  This limitation is a PITA.  Should we add a Slicer
>     meta-range
>      > that takes a finite random-access range and bolts slicing on in the
>      > obvious but relatively inefficient way if it's not already
>     supported and
>      > simply returns the range if it already supports slicing?  This
>     would be
>      > used under the hood when slicing is required.  For example:
>      >
>      > struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {
>      >      R range;
>      >      size_t lowerLim, upperLim;
>      >
>      >      this(R r) {
>      >           this.range = range;
>      >           this.upperLim = range.length;
>      >      }
>      >
>      >      // Range primitives:  front, popFront, etc.
>      >
>      >      typeof(this) opSlice(size_t lower, size_t upper) {
>      >          // Error checking
>      >          auto ret = this;
>      >          ret.upperLim -= this.length - upper;
>      >          ret.lowerLim += lower;
>      >          return ret;
>      >      }
>      > }
>      >
>      > auto slicer(R)(R range) {
>      >      static if(hasSlicing!R) {
>      >          return range;
>      >      } else {
>      >           return Slicer!(R)(range);
>      >      }
>      > }
>      > _______________________________________________
>      > phobos mailing list
>      > phobos at puremagic.com <mailto:phobos at puremagic.com>
>      > http://lists.puremagic.com/mailman/listinfo/phobos
> 
>     I'm not sure I like the idea that this would be done without programmer
>     intervention. If it's inefficient, it'll lead to programmers using
>     range types
>     with algorithms that really aren't supposed to take those range
>     types and
>     without them realizing the fact that it's inefficient. Having a
>     means to allow the
>     programmer to wrap a range to allow it to be used by an algorithm
>     which it
>     wouldn't normally work with may be a good idea, but each algorithm
>     takes certain
>     types of ranges for a reason, and I'd hate to see much impact to
>     efficiency
>     because of internal range wrangling that the programmer using the
>     function isn't
>     even aware of.
> 
>     - Jonathan M Davis
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

But this would lead to boilerplate and inefficiency in cases where slicing isn't needed.  Ranges that don't have a better way of dealing with slicing would have to have lowerLim and upperLim variables and add lowerLim every time the range was indexed.  While I think the overhead of this is reasonable if the alternative is an algorithm simply not working, I don't think it's reasonable to pay for it (both in execution efficiency and boilerplate code) when it's not going to be used.

On Fri, Aug 13, 2010 at 2:04 PM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> I'd favor simplicity by just requiring random-access ranges to define slicing.
>
> Andrei
>
> David Simcha wrote:
>
>> I would agree if we were talking about big-O efficiency, or even a large constant overhead, but IMHO avoiding Slicer is a micro-optimization, not a macro-optimization.  Therefore, by default it should "just work" even if it's slightly inefficient and intervention should be required only if the programmer decides it needs to be optimized.
>>
>> On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis <jmdavisprog at gmail.com<mailto: jmdavisprog at gmail.com>> wrote:
>>
>>    On Thursday, August 12, 2010 20:24:03 David Simcha wrote:
>>     > A whole bunch of stuff in Phobos (including std.range.Radial and
>>    the FFT
>>     > algorithm I just checked in) requires that ranges provided to it
>> have
>>     > slicing.  This limitation is a PITA.  Should we add a Slicer
>>    meta-range
>>     > that takes a finite random-access range and bolts slicing on in the
>>     > obvious but relatively inefficient way if it's not already
>>    supported and
>>     > simply returns the range if it already supports slicing?  This
>>    would be
>>     > used under the hood when slicing is required.  For example:
>>     >
>>     > struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {
>>     >      R range;
>>     >      size_t lowerLim, upperLim;
>>     >
>>     >      this(R r) {
>>     >           this.range = range;
>>     >           this.upperLim = range.length;
>>     >      }
>>     >
>>     >      // Range primitives:  front, popFront, etc.
>>     >
>>     >      typeof(this) opSlice(size_t lower, size_t upper) {
>>     >          // Error checking
>>     >          auto ret = this;
>>     >          ret.upperLim -= this.length - upper;
>>     >          ret.lowerLim += lower;
>>     >          return ret;
>>     >      }
>>     > }
>>     >
>>     > auto slicer(R)(R range) {
>>     >      static if(hasSlicing!R) {
>>     >          return range;
>>     >      } else {
>>     >           return Slicer!(R)(range);
>>     >      }
>>     > }
>>     > _______________________________________________
>>     > phobos mailing list
>>     > phobos at puremagic.com <mailto:phobos at puremagic.com>
>>
>>     > http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>    I'm not sure I like the idea that this would be done without programmer
>>    intervention. If it's inefficient, it'll lead to programmers using
>>    range types
>>    with algorithms that really aren't supposed to take those range
>>    types and
>>    without them realizing the fact that it's inefficient. Having a
>>    means to allow the
>>    programmer to wrap a range to allow it to be used by an algorithm
>>    which it
>>    wouldn't normally work with may be a good idea, but each algorithm
>>    takes certain
>>    types of ranges for a reason, and I'd hate to see much impact to
>>    efficiency
>>    because of internal range wrangling that the programmer using the
>>    function isn't
>>    even aware of.
>>
>>    - Jonathan M Davis
>>    _______________________________________________
>>    phobos mailing list
>>    phobos at puremagic.com <mailto:phobos at puremagic.com>
>>
>>    http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100813/a83aae9a/attachment.html>

On Friday, August 13, 2010 14:19:34 David Simcha wrote:
> But this would lead to boilerplate and inefficiency in cases where slicing isn't needed.  Ranges that don't have a better way of dealing with slicing would have to have lowerLim and upperLim variables and add lowerLim every time the range was indexed.  While I think the overhead of this is reasonable if the alternative is an algorithm simply not working, I don't think it's reasonable to pay for it (both in execution efficiency and boilerplate code) when it's not going to be used.

Maybe, random access ranges are just too tied up with arrays in my head, but I don't see why it would make sense for a random access range _not_ to have slicing like arrays do. In fact, now that I think about it, it surprises me that that's not a requirement of random access ranges.

Now, it wouldn't be all that hard to have a string mixin or a template or somesuch which produced boiler-plate slicing code in order to reduce code duplication, but I really don't understand why random access ranges wouldn't have slicing. Ideally, _any_ range would, it just wouldn't be efficient to take anything but the whole slice for anything that isn't random access.

- Jonathan M Davis

I'm just saying it's reasonable to require ranges to define slicing. I understand that that may feel some creators of random-access ranges aggravated, but it's not like we define five random-access ranges a day.

Let's require slicing (I meant to do that for a long time) and move on to more interesting problems. I just don't feel a slicer wrapper justifies itself.


Andrei

David Simcha wrote:
> But this would lead to boilerplate and inefficiency in cases where slicing isn't needed.  Ranges that don't have a better way of dealing with slicing would have to have lowerLim and upperLim variables and add lowerLim every time the range was indexed.  While I think the overhead of this is reasonable if the alternative is an algorithm simply not working, I don't think it's reasonable to pay for it (both in execution efficiency and boilerplate code) when it's not going to be used.
> 
> On Fri, Aug 13, 2010 at 2:04 PM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
> 
>     I'd favor simplicity by just requiring random-access ranges to
>     define slicing.
> 
>     Andrei
> 
>     David Simcha wrote:
> 
>         I would agree if we were talking about big-O efficiency, or even
>         a large constant overhead, but IMHO avoiding Slicer is a
>         micro-optimization, not a macro-optimization.  Therefore, by
>         default it should "just work" even if it's slightly inefficient
>         and intervention should be required only if the programmer
>         decides it needs to be optimized.
> 
>         On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis
>         <jmdavisprog at gmail.com <mailto:jmdavisprog at gmail.com>
>         <mailto:jmdavisprog at gmail.com <mailto:jmdavisprog at gmail.com>>>
>         wrote:
> 
>            On Thursday, August 12, 2010 20:24:03 David Simcha wrote:
>             > A whole bunch of stuff in Phobos (including
>         std.range.Radial and
>            the FFT
>             > algorithm I just checked in) requires that ranges provided
>         to it have
>             > slicing.  This limitation is a PITA.  Should we add a Slicer
>            meta-range
>             > that takes a finite random-access range and bolts slicing
>         on in the
>             > obvious but relatively inefficient way if it's not already
>            supported and
>             > simply returns the range if it already supports slicing?  This
>            would be
>             > used under the hood when slicing is required.  For example:
>             >
>             > struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {
>             >      R range;
>             >      size_t lowerLim, upperLim;
>             >
>             >      this(R r) {
>             >           this.range = range;
>             >           this.upperLim = range.length;
>             >      }
>             >
>             >      // Range primitives:  front, popFront, etc.
>             >
>             >      typeof(this) opSlice(size_t lower, size_t upper) {
>             >          // Error checking
>             >          auto ret = this;
>             >          ret.upperLim -= this.length - upper;
>             >          ret.lowerLim += lower;
>             >          return ret;
>             >      }
>             > }
>             >
>             > auto slicer(R)(R range) {
>             >      static if(hasSlicing!R) {
>             >          return range;
>             >      } else {
>             >           return Slicer!(R)(range);
>             >      }
>             > }
>             > _______________________________________________
>             > phobos mailing list
>             > phobos at puremagic.com <mailto:phobos at puremagic.com>
>         <mailto:phobos at puremagic.com <mailto:phobos at puremagic.com>>
> 
>             > http://lists.puremagic.com/mailman/listinfo/phobos
> 
>            I'm not sure I like the idea that this would be done without
>         programmer
>            intervention. If it's inefficient, it'll lead to programmers
>         using
>            range types
>            with algorithms that really aren't supposed to take those range
>            types and
>            without them realizing the fact that it's inefficient. Having a
>            means to allow the
>            programmer to wrap a range to allow it to be used by an algorithm
>            which it
>            wouldn't normally work with may be a good idea, but each
>         algorithm
>            takes certain
>            types of ranges for a reason, and I'd hate to see much impact to
>            efficiency
>            because of internal range wrangling that the programmer using the
>            function isn't
>            even aware of.
> 
>            - Jonathan M Davis
>            _______________________________________________
>            phobos mailing list
>            phobos at puremagic.com <mailto:phobos at puremagic.com>
>         <mailto:phobos at puremagic.com <mailto:phobos at puremagic.com>>
> 
>            http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> 
>         ------------------------------------------------------------------------
> 
> 
>         _______________________________________________
>         phobos mailing list
>         phobos at puremagic.com <mailto:phobos at puremagic.com>
>         http://lists.puremagic.com/mailman/listinfo/phobos
> 
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Ok, I've mostly been convinced.  I browsed through std.range and couldn't find any case of ranges that were finite and random access, but where that slicing would be difficult to implement provided that, in the case of higher order ranges, the base range supports slicing.

The one somewhat difficult case is when you take a finite number of elements from an infinite range.  I assume we don't want to make infinite ranges support slicing, as this would be kind of silly.  For example, other than an infinite random access range specialization of Take that simply maintains a lowerLim variable in addition to an upperLim variable (which is not unreasonable), I don't see any way to support slicing like:

take(cycle([1,2,3]), 100)[31..41];

In practice it seems like there are three basic types of random access ranges (as it's difficult to imagine any other cases where you'd have O(1) access to every element and dense 0..N indexing):

1.  Arrays and array-like objects that are implemented as a contiguous
block of memory.
2.  Iota, Sequence, Repeat/Replicate, etc., which are based on
evaluation of mathematical functions.
3.  Higher order ranges using (1) or (2) as the base range.

In all of these cases supporting slicing is completely feasible.  If we're sure we agree, I'll fold this into the bug fixing/cleanup I've resumed in std.range.

On 8/13/2010 5:47 PM, Andrei Alexandrescu wrote:
> I'm just saying it's reasonable to require ranges to define slicing. I understand that that may feel some creators of random-access ranges aggravated, but it's not like we define five random-access ranges a day.
>
> Let's require slicing (I meant to do that for a long time) and move on to more interesting problems. I just don't feel a slicer wrapper justifies itself.
>
>
> Andrei
>
> David Simcha wrote:
>> But this would lead to boilerplate and inefficiency in cases where slicing isn't needed.  Ranges that don't have a better way of dealing with slicing would have to have lowerLim and upperLim variables and add lowerLim every time the range was indexed.  While I think the overhead of this is reasonable if the alternative is an algorithm simply not working, I don't think it's reasonable to pay for it (both in execution efficiency and boilerplate code) when it's not going to be used.
>>
>> On Fri, Aug 13, 2010 at 2:04 PM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
>>
>>     I'd favor simplicity by just requiring random-access ranges to
>>     define slicing.
>>
>>     Andrei
>>
>>     David Simcha wrote:
>>
>>         I would agree if we were talking about big-O efficiency, or even
>>         a large constant overhead, but IMHO avoiding Slicer is a
>>         micro-optimization, not a macro-optimization.  Therefore, by
>>         default it should "just work" even if it's slightly inefficient
>>         and intervention should be required only if the programmer
>>         decides it needs to be optimized.
>>
>>         On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis
>> <jmdavisprog at gmail.com <mailto:jmdavisprog at gmail.com>
>> <mailto:jmdavisprog at gmail.com <mailto:jmdavisprog at gmail.com>>>
>>         wrote:
>>
>>            On Thursday, August 12, 2010 20:24:03 David Simcha wrote:
>> > A whole bunch of stuff in Phobos (including
>>         std.range.Radial and
>>            the FFT
>> > algorithm I just checked in) requires that ranges provided
>>         to it have
>> > slicing.  This limitation is a PITA.  Should we add a Slicer
>>            meta-range
>> > that takes a finite random-access range and bolts slicing
>>         on in the
>> > obvious but relatively inefficient way if it's not already
>>            supported and
>> > simply returns the range if it already supports slicing?  This
>>            would be
>> > used under the hood when slicing is required.  For example:
>> >
>> > struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {
>> >      R range;
>> >      size_t lowerLim, upperLim;
>> >
>> >      this(R r) {
>> >           this.range = range;
>> >           this.upperLim = range.length;
>> >      }
>> >
>> >      // Range primitives:  front, popFront, etc.
>> >
>> >      typeof(this) opSlice(size_t lower, size_t upper) {
>> >          // Error checking
>> >          auto ret = this;
>> >          ret.upperLim -= this.length - upper;
>> >          ret.lowerLim += lower;
>> >          return ret;
>> >      }
>> > }
>> >
>> > auto slicer(R)(R range) {
>> >      static if(hasSlicing!R) {
>> >          return range;
>> >      } else {
>> >           return Slicer!(R)(range);
>> >      }
>> > }
>> > _______________________________________________
>> > phobos mailing list
>> > phobos at puremagic.com <mailto:phobos at puremagic.com>
>> <mailto:phobos at puremagic.com <mailto:phobos at puremagic.com>>
>>
>> > http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>            I'm not sure I like the idea that this would be done without
>>         programmer
>>            intervention. If it's inefficient, it'll lead to programmers
>>         using
>>            range types
>>            with algorithms that really aren't supposed to take those
>> range
>>            types and
>>            without them realizing the fact that it's inefficient.
>> Having a
>>            means to allow the
>>            programmer to wrap a range to allow it to be used by an
>> algorithm
>>            which it
>>            wouldn't normally work with may be a good idea, but each
>>         algorithm
>>            takes certain
>>            types of ranges for a reason, and I'd hate to see much
>> impact to
>>            efficiency
>>            because of internal range wrangling that the programmer
>> using the
>>            function isn't
>>            even aware of.
>>
>>            - Jonathan M Davis
>>            _______________________________________________
>>            phobos mailing list
>>            phobos at puremagic.com <mailto:phobos at puremagic.com>
>> <mailto:phobos at puremagic.com <mailto:phobos at puremagic.com>>
>>
>>            http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>
>>
>> 
>> ------------------------------------------------------------------------
>>
>>
>>         _______________________________________________
>>         phobos mailing list
>>         phobos at puremagic.com <mailto:phobos at puremagic.com>
>>         http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>     _______________________________________________
>>     phobos mailing list
>>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>>     http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>