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...
2013/8/25 maarten van damme <maartenvd1...@gmail.com> > 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. > > 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...) > And while I haven't worked in c++, even that appears to have remove_copy > which is really what I want. > > I could use temporary variables and blow that neat line up in 3 lines > which, while still readable, look redundant. > > 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). > > > 2013/8/25 Brad Anderson <e...@gnuk.net> > >> On Sunday, 25 August 2013 at 02:24:30 UTC, maarten van damme wrote: >> >>> hello, >>> >>> I'm a hobyist-programmer and around where I live there's a group of >>> haskell >>> fanatics. They posted solutions to a recent programming challenge which I >>> find to be a bit ugly. For fun I wanted to implement it in d and a rough >>> version (not correct yet, this was written/hacked in 5 minutes after >>> reading the exercise) >>> >>> My rough version is posted here : http://dpaste.dzfl.pl/4b5a6578 >>> >>> if you look at the output, you'll see this particular line : >>> "omkom -> komkom because of : kom momkom momkom -> momkomm" >>> >>> This is because of what remove from std.algorithm does. It not only >>> returns >>> a range with that element removed (as the name implies), it also modifies >>> the original range. >>> I assume this decision was made for efficiency purposes but that is one >>> of >>> the most ugliest things I have ever come across. At least c# forces the >>> 'ref' in it's parameters so you know something's up. Is there any way I >>> could've known this? (apart from reading the documentation on every >>> single >>> trivial function in the std library?) >>> >> >> 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. >> >> 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). >> > >
