Add Error Polymorphism to High-Order Functions in array Modules

[Asterless]

Summary

This PR supplements the higher-order functions that were omitted in #2211

Details

Affected Functions

• Array

  • makei

• FixedArray

  • each
  • makei
  • rev_each

• View

  • map
  • mapi

These updates ensure a more robust and consistent approach to error handling across the array-related modules.

[peter-jerry-ye-code-review]

Incorrect early return type in Array::makei implementation

Category
Correctness
Code Snippet
pub fn[T] Array::makei(length : Int, value : (Int) -> T?Error) -> Array[T]?Error {
if length <= 0 {
[]
} else {
Recommendation
Change early return to be explicit about error handling:

if length <= 0 {
  return ok([])
} else {

Reasoning
Since the function signature promises Array[T]?Error return type, returning just [] without wrapping in ok() is incorrect and inconsistent with error handling pattern. This could cause type checking issues.

Missing error propagation in View::map loop implementation

Category
Maintainability
Code Snippet
pub fn[T, U] View::map(self : View[T], f : (T) -> U?Error) -> Array[U]?Error {
if self.length() == 0 {
return []
}
Recommendation
Add proper error handling in the implementation:

if self.length() == 0 {
  return ok([])
}

Reasoning
The function now accepts callbacks that can fail with errors, but the implementation doesn't show how these errors are propagated. Need to ensure errors from the callback are properly handled and propagated.

Inconsistent documentation examples with new error handling

Category
Maintainability
Code Snippet
/// /// [1, 2, 3, 4, 5].each(fn(x){ arr.push(x) }) /// assert_eq(arr, [1, 2, 3, 4, 5]) ///
Recommendation
Update documentation examples to reflect error handling:

/// ```
/// try {
///   [1, 2, 3, 4, 5].each(fn(x){ arr.push(x) })
///   assert_eq(arr, [1, 2, 3, 4, 5])
/// }
/// ```
**Reasoning**
The documentation examples don't reflect the new error handling capabilities of these functions. Examples should demonstrate proper error handling to guide developers in correct usage.

</details>

[coveralls]

Pull Request Test Coverage Report for Build 7193

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 93.105%

---

Totals
Change from base Build 7188:	0.0%
Covered Lines:	8574
Relevant Lines:	9209

---

💛 - Coveralls

[peter-jerry-ye]

This one uses intrinsics, so it can't be modified like this directly. @Yu-zh

[Asterless]

Should I remove my changes?

[peter-jerry-ye]

We will remove the intrinsic for now.

[bobzhang]

can you do a rebase? there is a rebase conflict

[Asterless]

can you do a rebase? there is a rebase conflict

There are too many problems that rebase needs to solve. Maybe creating a new branch would be better🥲

[peter-jerry-ye]

can you do a rebase? there is a rebase conflict

There are too many problems that rebase needs to solve. Maybe creating a new branch would be better🥲

You need to improve your github workflow.

[Asterless]

can you do a rebase? there is a rebase conflict

There are too many problems that rebase needs to solve. Maybe creating a new branch would be better🥲

You need to improve your github workflow.

Thank you for your reminder! Actually, I have already realized this problem and won't make the same mistake again next time