std.algorithm's remove

[maarten van damme]

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 <maartenvd1994 at 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 <eco at 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).
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20130825/a91831ae/attachment.html>