Skip to content

Conversation

@AStepanov25
Copy link
Contributor

No description provided.

@AStepanov25 AStepanov25 requested a review from a team as a code owner October 19, 2025 14:39
rvanasa
rvanasa previously approved these changes Oct 24, 2025
Copy link
Collaborator

@rvanasa rvanasa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@github-actions github-actions bot dismissed rvanasa’s stale review November 5, 2025 13:13

Review dismissed by automation script.

@timohanke
Copy link
Contributor

There are probably many functions in the List module that could benefit from a variant that operates on a "range" (= sublist) instead of on the whole list. This is just one example. Therefore it might make sense to hold off on this one and wait to see all the other functions. Then it will be easier to find a consistent naming scheme and consistent argument pattern to define the range.

The current name forEachRange isn't consistent with forEachEntry because we are not applying something "for each range". Maybe forEachInRange?

Regarding argument pattern:

  • shall it be list, from, to, f instead of list, f, from, to?
  • shall list, from, to be grouped into a tuple?

We can also wait for implicits to be released because range start or end could have a default value.

In light of this, shall we make this PR a draft at this point so it doesn't accidentally get merged?

@rvanasa
Copy link
Collaborator

rvanasa commented Nov 11, 2025

Maybe forEachInRange?
👍

shall it be list, from, to, f instead of list, f, from, to? / shall list, from, to be grouped into a tuple?

My preference is the current implementation (list, f, from, to) although we could see what others think before merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants