Thread overview
Navigating tradeoffs in bidirectional filter design
Jan 09
monkyyy
Jan 10
monkyyy
January 09

a unidirectional range filter can be implimented as simply as:

auto find(alias F,R)(R r){
	while( ! r.empty && ! F(r.front)){
		r.popFront;
	}
	return r;
}
unittest{
	counter(5).find!(a=>a==3).summery;
}
auto findnext(alias F,R)(R r){
	r.popFront;
	return r.find!F;
}
auto filter(alias F,R)(R r){
	struct Filter{
		R r;
		auto ref front()=>r.front;
		void popFront(){r=r.findnext!F;}
		bool empty()=>r.empty;
	}
	return Filter(r.find!F);
}
unittest{
	counter(10).filter!(a=>a%3).summery;//[1, 2, 4, 5, 7, 8]
}

Im aware phoboes takes ....more complexity to implement filter and there should be some extra complexity to make a bidirectional filter, but when I ussally look into phoboes 1000 line functions I usually make different tradeoffs. What are the actual considerations here?

January 10

On Thursday, 9 January 2025 at 21:56:59 UTC, monkyyy wrote:

>

Im aware phoboes takes ....more complexity to implement filter and there should be some extra complexity to make a bidirectional filter, but when I ussally look into phoboes 1000 line functions I usually make different tradeoffs. What are the actual considerations here?

I don't really understand, what needs to be considerations? Isn't the interface below sufficient?

auto filter(alias F,R)(R r)
{
  struct Filter
  {
    R r;
    auto back()     => r.back;
    auto front()    => r.front;
    auto popFront() => r = r.findNext!F;
    auto popBack()  => r = r.findPrevious!F;
    auto empty()    => r.empty;
    auto save()     => r.save;
  }
  return Filter(r.find!F);
}

SDB@79

January 10

On Friday, 10 January 2025 at 02:47:24 UTC, Salih Dincer wrote:

>

On Thursday, 9 January 2025 at 21:56:59 UTC, monkyyy wrote:

>

Im aware phoboes takes ....more complexity to implement filter and there should be some extra complexity to make a bidirectional filter, but when I ussally look into phoboes 1000 line functions I usually make different tradeoffs. What are the actual considerations here?

I don't really understand, what needs to be considerations? Isn't the interface below sufficient?

auto filter(alias F,R)(R r)
{
  struct Filter
  {
    R r;
    auto back()     => r.back;
    auto front()    => r.front;
    auto popFront() => r = r.findNext!F;
    auto popBack()  => r = r.findPrevious!F;
    auto empty()    => r.empty;
    auto save()     => r.save;
  }
  return Filter(r.find!F);
}

SDB@79

Well:

  1. [1,2,3,4,5].Filter!(a=>a==3).back should equal 3, in yours it will equal 5
  2. your no longer supporting unidirectional ranges

And that only what I notice without any testing; I feel worse about being eager for back then front

January 11

On Friday, 10 January 2025 at 03:16:51 UTC, monkyyy wrote:

>

Well:

  1. [1,2,3,4,5].Filter!(a=>a==3).back should equal 3, in yours it will equal 5

Thank you for your notice. I tested your notice and I think you are wrong. So you are confusing front() with back().

SDB@79