Skip to content

feat: add eval for direct immutable array mapping #59

Description

@martinfrancois

Problem

The Streams capture workflow missed a mapping simplification from an adapter-plus-copy chain to the direct immutable factory. This is eval-worthy because .map(List::of) is only safe when target typing makes the source array the varargs elements and the snapshot, null, order, and mutability contracts match.

Area

Evals or scoring

Describe the solution you want

Add a natural reference eval for collapsing List.copyOf(Arrays.asList(array)) inside a mapping pipeline to List::of, with explicit varargs-array safety checks.

Code before the prompt was executed

Optional<List<String>> arguments(Optional<String[]> source) {
    return source.map(values -> List.copyOf(Arrays.asList(values)));
}

Prompt that caused the implementation

The original prompt required a complete Java-source API-reuse audit:

  • Audit every tracked Java source for worthwhile replacements with the Java standard library or a directly declared dependency.
  • Implement only changes that clearly reduce code, complexity, duplication, or maintenance risk.
  • Preserve observable behavior, ordering, failure semantics, null handling, concurrency, security, and relevant performance characteristics.
  • Add focused regression tests for each affected boundary.

The prompt should have activated collection/stream capture even though the outer mapping API is Optional.map, because the implementation replaces a collection transformation inside a fluent pipeline.

Later prompt that exposed the issue

A maintainer later asked whether the Streams capture issue had been created and requested that the capture skill remember adjacent collection mappings such as this.

Prompt-produced code before maintainer correction

Optional<List<String>> arguments(Optional<String[]> source) {
    return source.map(List::of);
}

The code is preferred, but the reusable lesson was not captured.

Why the prompt-produced code is weak

The resulting code is not weak; the process is. The capture workflow did not recognize an adapter-plus-copy simplification because no Stream instance appears in the final line. That loses an eval with a subtle overload boundary.

Behavior-equivalence analysis

The rewrite must preserve empty and non-empty arrays, encounter order, an unmodifiable result, a defensive snapshot rather than an array-backed view, null-element rejection, and empty-Optional behavior. Later mutation of the source array must not affect the result. A cast or different target type can instead create List<String[]>, so target typing must be proven.

Maintainer-preferred code

Optional<List<String>> arguments(Optional<String[]> source) {
    return source.map(List::of);
}

Why the replacement is better

The factory directly states the required immutable snapshot and removes Arrays.asList plus List.copyOf plumbing. The method reference keeps the mapping operation concise once type resolution proves the overload.

Desired eval behavior

  • Reward activating during the original API-audit prompt.
  • Reward the direct method reference only after proving varargs flattening and result typing.
  • Reward tests for empty arrays, order, null elements, source-array mutation, immutability, and empty Optional.
  • Reward retaining a lambda when conversion logic is actually required.

Anti-patterns the eval should reject

  • Collections.unmodifiableList(Arrays.asList(array)), which retains an array-backed view.
  • A cast or target type that creates one String[] element.
  • Treating all method references as automatically clearer or equivalent.
  • Ignoring null-element behavior or source-array mutation.

Suggested eval name

direct-immutable-array-map

Examples

Use the minimal Optional mapping above. Start it in evals-reference/; add concise runtime guidance and a precise Java 9 List.of(E...) compatibility note only as supported by the classified result.

Alternatives considered

A generic method-reference eval would be too broad and would miss the varargs-array equivalence risk. No open Streams issue covers this pattern.

Current workaround

Manually inspect adapter-plus-copy mappings and verify the selected factory overload with the compiler and focused tests.

Additional context

No user-facing contract change is intended.

AI Assistance

  • AI-assisted issue
  • I confirm I understand and reviewed this request

AI prompts / session logs (optional)

Prepared with Codex assistance from a maintainer review of a behavior-preserving Java API-reuse audit.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions