sortUniq

[H. S. Teoh via Digitalmars-d]

On Sat, Jan 24, 2015 at 11:20:55AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 1/24/15 11:00 AM, H. S. Teoh via Digitalmars-d wrote:
> >On Sat, Jan 24, 2015 at 10:35:13AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
[...]
> >>For filter it's a forward range if input is forward or better. --
> >>Andrei
> >
> >Hmm. Couldn't filter be made bidirectional too, if the underlying
> >range is also bidirectional? After all, filtering doesn't depend on
> >the surrounding elements, so in theory you should be able to popBack
> >as well.
> 
> History: http://dlang.org/phobos/std_algorithm.html#.filterBidirectional
[...]

Ah, I should have known, since I do remember seeing this when splitting
std.algorithm. I guess it didn't really register beyond "this function
belongs in std.algorithm.iteration". :-P

It's kinda sad that we can't merge the two functions and make it so that
the initial scanning of .back only happens lazily. I mean, in theory,
this should be easy:

	struct Filter {
		R range;
		...
		@property auto back() {
			while (!range.empty && !pred(range.back))
				range.popBack();
			return range.back;
		}
		void popBack() {
			range.popBack();
		}
	}

But I remember there was a huge discussion over whether
.front/.back/.empty should do any non-trivial work. The current
implementation appears to be the consequence of shoehorning all work
into popFront/popBack. But in my mind, these methods ought to be
abstract, and the user shouldn't be able to see any difference in
behaviour regardless of where the real work is actually done.


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth