<br><br><div class="gmail_quote">On Tue, May 28, 2013 at 3:20 AM, bearophile <span dir="ltr"><<a href="mailto:bearophileHUGS@lycos.com" target="_blank">bearophileHUGS@lycos.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Timothee Cour:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">

string a="ÙÙab";<br>
auto b1=a.map!(a=>"<"d~a~">"d).<u></u>array;<br></div><div class="im">
writeln(b1);//["<Ù>", "<Ù>", "<a>", "<b>", "", ""]<br>
Why are there 2 empty strings at the end? (one per Omega if you vary the<br>
</div></blockquote><div class="im">
number of such symbols in the string).<br>
<br></div><div class="im">
The above is just weird; is that a bug?<br>
</div></blockquote>
<br>
I think it's a bug, it's shown here, I will put it in Bugzilla:<br>
<br>
import std.stdio: writeln;<br>
import std.algorithm: map;<br>
import std.array: array;<br>
void main() {<br>
    string a = "ÙÙab";<br>
    a.map!(a => "<"d ~ a ~ ">"d).writeln;<br>
    a.map!(a => "<"d ~ a ~ ">"d).array.writeln;<br>
}<br>
<br>
<br>
The output shows that maybe it's a problem of array():<br>
<br>
["<Ù>", "<Ù>", "<a>", "<b>"]<div class="im"><br>
["<Ù>", "<Ù>", "<a>", "<b>", "", ""]<br>
<br>
<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For input ranges ranges, I don't understand why the compiler can't accept<br>
the foreach(i,ai;a) syntax:<br>
<br>
it should behave as follows:<br>
foreach(i , ai; a){expr}<br>
<br>
rewritten as:<br>
for(size_t i=0, ai=a.front; !a.empty; a.popFront;){expr}<br>
<br>
but it doesn't compile (it only accepts foreach(ai;a){expr}<br>
</blockquote>
<br></div>
The idea must work in all cases. For opApply, built-in arrays, built-in associative arrays and for ranges. I think it causes some clashing. If you will find it causes no clashing, then it's a candidate to become an enhancement request.<br>

<br>
Bye,<br>
bearophile<br>
</blockquote></div><br><div>thanks for filing 10191!</div><div><br></div><div>Let's dig more the indexed foreach proposal:</div><div><br></div><div>opApply => present with corresponding signature to foreach(i,ai;a) => use it</div>
<div>built-in arrays => its an randaccess iterator so already works</div><div>associative arrays => already works, compiler rewrites to key,value</div><div>ranges => if it's not an associative array, random access iterator, doesn't have opApply with corresponding signature, then use the size_t index I mentioned (existing code makes it compile error, this proposal allows it).</div>
<div><br></div><div>Where do you think it can cause clashing?</div><div><br></div>