<div dir="ltr">Correction, I could really use remove to begin with, only have to dup the range. Still convinced that the remove behaviour is counterintuitive but I assume good reasons exist...</div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/8/25 maarten van damme <span dir="ltr"><<a href="mailto:maartenvd1994@gmail.com" target="_blank">maartenvd1994@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">But remove doesn't truly remove from the source range because the length of the source range stays the same. It's return value is a modified copy of the source range.<div><br></div><div>Filter doesn't really work right away because that would also remove duplicate elements while I only want to remove at a given index. It also makes for clunkier looking code and is counterintinuitive to come up with (I want to remove an element therefore I have to filter every element that isn't equal to that element from the source range...)</div>
<div>And while I haven't worked in c++, even that appears to have remove_copy which is really what I want.<br></div><div><br></div><div>I could use temporary variables and blow that neat line up in 3 lines which, while still readable, look redundant.</div>
<div><br></div><div>I'm happy the d result is 3 times shorter then their haskell solution but not that the time spent was 5 minutes working and the rest of the time debugging. This as opposed to using racket where the time spent is 15 minutes but after that everything works great (while my racket experience is limited to playing around with it for 2 weeks now and then).</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/25 Brad Anderson <span dir="ltr"><<a href="mailto:eco@gnuk.net" target="_blank">eco@gnuk.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Sunday, 25 August 2013 at 02:24:30 UTC, maarten van damme wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hello,<br>
<br>
I'm a hobyist-programmer and around where I live there's a group of haskell<br>
fanatics. They posted solutions to a recent programming challenge which I<br>
find to be a bit ugly. For fun I wanted to implement it in d and a rough<br>
version (not correct yet, this was written/hacked in 5 minutes after<br>
reading the exercise)<br>
<br>
My rough version is posted here : <a href="http://dpaste.dzfl.pl/4b5a6578" target="_blank">http://dpaste.dzfl.pl/4b5a6578</a><br>
<br>
if you look at the output, you'll see this particular line :<br>
"omkom -> komkom because of : kom momkom momkom -> momkomm"<br>
<br>
This is because of what remove from std.algorithm does. It not only returns<br>
a range with that element removed (as the name implies), it also modifies<br>
the original range.<br>
I assume this decision was made for efficiency purposes but that is one of<br>
the most ugliest things I have ever come across. At least c# forces the<br>
'ref' in it's parameters so you know something's up. Is there any way I<br>
could've known this? (apart from reading the documentation on every single<br>
trivial function in the std library?)<br>
</blockquote>
<br></div></div>
It was done that way intentionally because the purpose of remove is to remove from the source range. If you don't want to affect the source range use filter.<br>
<br>
I suspect you could trace remove's lineage back to C++ STL's remove which works similarly (but is significantly clunkier and harder to use).<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>