www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - when should ranges be static

reply monkyyy <crazymonkyyy gmail.com> writes:
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.

---


 foo is a nested function and cannot be accessed by bar


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
Feb 06
parent reply Inkrementator <invalid invalid.org> writes:
On Thursday, 6 February 2025 at 20:08:36 UTC, monkyyy wrote:

 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.

 ---


 foo is a nested function and cannot be accessed by bar


 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


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
Feb 15
next sibling parent Inkrementator <invalid invalid.org> writes:
On Saturday, 15 February 2025 at 11:47:58 UTC, Inkrementator 
wrote:

 Wrapping foo in another delegate seems to at least compile.


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;
}
```
Feb 15
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 15 February 2025 at 11:47:58 UTC, Inkrementator 
wrote:

 I put `r.findnext!(i => F(i))` instead of `r.findnext!(F)`. I


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?
Feb 15
parent Inkrementator <invalid invalid.org> writes:
On Saturday, 15 February 2025 at 19:21:33 UTC, monkyyy wrote:

 On Saturday, 15 February 2025 at 11:47:58 UTC, Inkrementator 
 wrote:
 Would you expect that style change would remove this flavor of 
 bugs? Do you think this is a compiler bug?


It looks similar to this: 
https://github.com/dlang/dmd/issues/17733 I don't know enough 
whether this warrants another bug report. In the blocked 
suggested PR, this seems to be related to dual-context stuff, so 
your intuition might've right in that regard.

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;
	}
}
```

Would you expect that style change would remove this flavor of 
bugs?


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