<div class="gmail_quote">On Thu, Oct 14, 2010 at 10:45 AM, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3. Same discussion about decode. This is actually more important because you might want to decode streams of dchar. This is how many streams will come through, even though they are technically Ascii.<br><br></blockquote>
<div>Accepting string and wstring causes problems as they don&#39;t define length, and of course may contain non-ascii characters.  Is the phobos-standard way to assume they contain only ascii characters and take the array length as the string length?  (with checks in non-release mode)</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">@property ubyte[] front();<br> </blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Regarding Daniel&#39;s approach with char/byte level ranges through and through, in an ideal world I&#39;d agree. But I fear that the implementation would not be as efficient. (I suggest you benchmark it against Masahiro&#39;s.) Also, practically, more often than not I&#39;ll want to work one chunk at a time, not one byte/char at a time.<font color="#888888"><span class="Apple-style-span" style="color: rgb(0, 0, 0); "><div>
</div></span></font></blockquote><div> </div><div>I could be wrong, but I don&#39;t think I&#39;ve seen any ranges in phobos that return more than one logical unit from front.  I understand this is common with streams, but I&#39;m unsure what the phobos policy is on doing this with ranges.</div>
<div><br></div><div>A set of ranges that convert char[4] &lt;=&gt; ubyte[3] could be an option, but the output would need to be flattened in order to use it with many algorithms.  You may want to convert by chunks, but you usually want to work with a range of ubyte/char, not a range of ubyte[]/char[].</div>
<div><br></div><div>I will do some benchmarks to see how much worse the range-based solution performs.  I assume doesn&#39;t compare very well for the buffer -&gt; buffer case, but still fares better some applications. (eg. searching and other things that don&#39;t need to convert the entire range).</div>
<div><br></div><div>Daniel.</div></div>