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.<br>
<br><div class="gmail_quote">On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisprog@gmail.com">jmdavisprog@gmail.com</a>></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>
> A whole bunch of stuff in Phobos (including std.range.Radial and the FFT<br>
> algorithm I just checked in) requires that ranges provided to it have<br>
> slicing. This limitation is a PITA. Should we add a Slicer meta-range<br>
> that takes a finite random-access range and bolts slicing on in the<br>
> obvious but relatively inefficient way if it's not already supported and<br>
> simply returns the range if it already supports slicing? This would be<br>
> used under the hood when slicing is required. For example:<br>
><br>
> struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {<br>
> R range;<br>
> size_t lowerLim, upperLim;<br>
><br>
> this(R r) {<br>
> this.range = range;<br>
> this.upperLim = range.length;<br>
> }<br>
><br>
> // Range primitives: front, popFront, etc.<br>
><br>
> typeof(this) opSlice(size_t lower, size_t upper) {<br>
> // Error checking<br>
> auto ret = this;<br>
> ret.upperLim -= this.length - upper;<br>
> ret.lowerLim += lower;<br>
> return ret;<br>
> }<br>
> }<br>
><br>
> auto slicer(R)(R range) {<br>
> static if(hasSlicing!R) {<br>
> return range;<br>
> } else {<br>
> return Slicer!(R)(range);<br>
> }<br>
> }<br>
</div></div>> _______________________________________________<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>
<br>
I'm not sure I like the idea that this would be done without programmer<br>
intervention. If it's inefficient, it'll lead to programmers using range types<br>
with algorithms that really aren't supposed to take those range types and<br>
without them realizing the fact that it'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't normally work with may be a good idea, but each algorithm takes certain<br>
types of ranges for a reason, and I'd hate to see much impact to efficiency<br>
because of internal range wrangling that the programmer using the function isn'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>