8000 Modernize closures with arrow functions by bobzhang · Pull Request #2335 · moonbitlang/core · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Modernize closures with arrow functions #2335

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jun 24, 2025

Conversation

bobzhang
Copy link
Contributor

Summary

  • document arrow function support in README
  • use arrow syntax for closures across data structures and tests
  • keep formatting and interfaces updated

Testing

  • moon check
  • moon test

https://chatgpt.com/codex/tasks/task_e_685aa471e78c8320961fad28d06a3f25

Copy link
peter-jerry-ye-code-review bot commented Jun 24, 2025
Consistent closure syntax migration

Category
Maintainability
Code Snippet
Before: arr.each(fn(e) { m.set(e.0, e.1) })
After: arr.each(e => m.set(e.0, e.1))
Recommendation
The changes look good - continue migrating all closures to arrow syntax for consistency
Reasoning
The arrow syntax makes the code more concise and modern while maintaining readability. The consistent application across the codebase improves maintainability.

Nested closure indentation improvements

Category
Maintainability
Code Snippet
pub fn[K, V] iter(self : T[K, V]) -> Iter[(K, V)] {
Iter::new(yield_ => for entry in self.entries {
if entry is Some({ key, value, .. })
Recommendation
Consider extracting complex nested arrow functions to named functions if they grow beyond 3-4 levels of nesting
Reasoning
While the arrow syntax is cleaner, deeply nested closures can still become hard to read. Breaking them into named functions when they grow complex helps maintainability.

Closure parameter naming consistency

Category
Correctness
Code Snippet
m.each((_k, v) => sum += v)
m.eachi((i, _k, v) => {...})
Recommendation
Use consistent parameter naming patterns across similar callbacks - if unused params are prefixed with _ in one place, maintain that pattern everywhere
Reasoning
Consistent parameter naming conventions help readers understand the code's intent and which parameters are intentionally unused vs accidentally ignored.

@coveralls
Copy link
Collaborator
coveralls commented Jun 24, 2025

Pull Request Test Coverage Report for Build 7499

Details

  • 12 of 12 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.003%) to 89.375%

Totals Coverage Status
Change from base Build 7491: -0.003%
Covered Lines: 3533
Relevant Lines: 3953

💛 - Coveralls

@bobzhang bobzhang enabled auto-merge (rebase) June 24, 2025 13:53
@bobzhang bobzhang merged commit a622c68 into main Jun 24, 2025
12 checks passed
@bobzhang bobzhang deleted the codex/modernize-codebase-with-arrow-functions branch June 24, 2025 13:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0