I have template hell code; eventually 5 nested range calls have dual context-y issues and maybe compiler bugs; adding static makes those errors go away, adding static to everything makes new bugs.

Wack-a-mole when the compiler gets confused about context is not a long term solution and for all I know, wont even be stable.

When foo and bar are a top level range functions; this error is nonsense, but im treating it like a dual context error because it seems to act that way.

https://github.com/crazymonkyyy/ref-algorithms/blob/master/refalgorithm.d

On Thursday, 6 February 2025 at 20:08:36 UTC, monkyyy wrote:

Wrapping foo in another delegate seems to at least compile.

auto split(alias F,R)(R r){
	static struct splitter{
		R r;
		auto front()=>r.takeuntil(r.findnext!(i => F(i)));
		void popFront(){r=r.findnext!(i => F(i));}
		bool empty()=>r.empty;
	}
	return splitter(r);
}

I put r.findnext!(i => F(i)) instead of r.findnext!(F). I don't understand why this works and haven't checked whether this actually saves allocations.d

On Saturday, 15 February 2025 at 11:47:58 UTC, Inkrementator wrote:

Same as splitting out the struct. I don't understand why a struct outside of a function gets treated differently than a static struct.

auto split(alias F,R)(R r){
	return splitter!(F,R)(r);
}

private struct splitter(alias F, R){
	R r;
	auto front()=>r.takeuntil(r.findnext!F);
	void popFront(){r=r.findnext!F;}
	bool empty()=>r.empty;
}

On Saturday, 15 February 2025 at 11:47:58 UTC, Inkrementator wrote:

hmmmm I would consider that a compiler bug if that ever changed the behavior but I see how that may de-confuse the compiler.

Would you expect that style change would remove this flavor of bugs? Do you think this is a compiler bug?

On Saturday, 15 February 2025 at 19:21:33 UTC, monkyyy wrote:

Another suggestion that works is desugaring the eponymous template and putting the struct in the template namespace.

template split(alias F,R){
	auto split(R r){
		return splitter(r);
	}

	private struct splitter{
		R r;
		auto front()=>r.takeuntil(r.findnext!F);
		void popFront(){r=r.findnext!F;}
		bool empty()=>r.empty;
	}
}

At least from spotchecking, this made most of the non-static structs work again after applying one of these transformations