Closed tobez closed 4 months ago
Yes, it would be good to be able to work with (then) standard iterators, but I still need to analyze what that means in more detail. I'm making myself smart, I've only skimmed through it so far and haven't gone any deeper yet. It would be a good opportunity to try it out for myself using a practical example. I'll keep you up to date.
nice summary from Eli: https://eli.thegreenplace.net/2023/preview-ranging-over-functions-in-go
again, the question about naming arises.
func (t *Table[V]) Walk(yield func(pfx netip.Prefix, val V) bool) bool
func (t *Table[V]) Walk4(yield func(pfx netip.Prefix, val V) bool) bool
func (t *Table[V]) Walk6(yield func(pfx netip.Prefix, val V) bool) bool
or
func (t *Table[V]) All(yield func(pfx netip.Prefix, val V) bool) bool
func (t *Table[V]) All4(yield func(pfx netip.Prefix, val V) bool) bool
func (t *Table[V]) All6(yield func(pfx netip.Prefix, val V) bool) bool
@tobez the devel branch is updated accordingly, please give it a try with gotip. Comments welcome.
ah, Eli had a prior version, the signature of the All() function changed, wait, I'll fix the devel branch.
Now I have used the correct signatures and tested with the gotip, there is a commented out TestRange.
I don't want to bump up the requirement higher than 1.21 yet.
By the way, go is the best at refactoring
devel merged and closed
If one changes the
WalkXXX()
signatures tothey will become compatible with rangefunc experiment, and if the experiment is enabled (but likely a default one day), syntactic niceties like this become possible:
What do you think?