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 &quot;just work&quot; even if it&#39;s slightly inefficient and intervention should be required only if the programmer decides it needs to be optimized.<br>
<br><div class="gmail_quote">On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis <span dir="ltr">&lt;<a href="mailto:jmdavisprog@gmail.com">jmdavisprog@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Thursday, August 12, 2010 20:24:03 David Simcha wrote:<br>
&gt; A whole bunch of stuff in Phobos (including std.range.Radial and the FFT<br>
&gt; algorithm I just checked in) requires that ranges provided to it have<br>
&gt; slicing.  This limitation is a PITA.  Should we add a Slicer meta-range<br>
&gt; that takes a finite random-access range and bolts slicing on in the<br>
&gt; obvious but relatively inefficient way if it&#39;s not already supported and<br>
&gt; simply returns the range if it already supports slicing?  This would be<br>
&gt; used under the hood when slicing is required.  For example:<br>
&gt;<br>
&gt; struct Slicer(R) if(isRandomAccessRange!R &amp;&amp; !hasSlicing!R) {<br>
&gt;      R range;<br>
&gt;      size_t lowerLim, upperLim;<br>
&gt;<br>
&gt;      this(R r) {<br>
&gt;           this.range = range;<br>
&gt;           this.upperLim = range.length;<br>
&gt;      }<br>
&gt;<br>
&gt;      // Range primitives:  front, popFront, etc.<br>
&gt;<br>
&gt;      typeof(this) opSlice(size_t lower, size_t upper) {<br>
&gt;          // Error checking<br>
&gt;          auto ret = this;<br>
&gt;          ret.upperLim -= this.length - upper;<br>
&gt;          ret.lowerLim += lower;<br>
&gt;          return ret;<br>
&gt;      }<br>
&gt; }<br>
&gt;<br>
&gt; auto slicer(R)(R range) {<br>
&gt;      static if(hasSlicing!R) {<br>
&gt;          return range;<br>
&gt;      } else {<br>
&gt;           return Slicer!(R)(range);<br>
&gt;      }<br>
&gt; }<br>
</div></div>&gt; _______________________________________________<br>
&gt; phobos mailing list<br>
&gt; <a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
&gt; <a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
<br>
I&#39;m not sure I like the idea that this would be done without programmer<br>
intervention. If it&#39;s inefficient, it&#39;ll lead to programmers using range types<br>
with algorithms that really aren&#39;t supposed to take those range types and<br>
without them realizing the fact that it&#39;s inefficient. Having a means to allow the<br>
programmer to wrap a range to allow it to be used by an algorithm which it<br>
wouldn&#39;t normally work with may be a good idea, but each algorithm takes certain<br>
types of ranges for a reason, and I&#39;d hate to see much impact to efficiency<br>
because of internal range wrangling that the programmer using the function isn&#39;t<br>
even aware of.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</font></blockquote></div><br>