[paulbalandan]

Description
Ref: https://forum.codeigniter.com/showthread.php?tid=94539

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[neznaika0]

Is there any point in checking the array for valid values? I think it’s an unnecessary burden. But the topic starter on the forum mentions this.

[neznaika0]

Is it worth adding a note in changelog about strict types in #10521 ? Previously, this was not approved as BC and was pushed to the next branch.

[paulbalandan]

Is it worth adding a note in changelog about strict types in #10521 ? Previously, this was not approved as BC and was pushed to the next branch.

#10521 didn't add strict_types. form_helper.php already declared it, and that PR added native return types. I checked every helper affected, and set_value() was the only one returning a caller-supplied value that could fall outside the new type. Overridden helpers are unaffected thanks to the function_exists() guards. The changelog entry here already records it as a v4.7.5 regression, so I don't think a separate note is needed.

[paulbalandan]

Is there any point in checking the array for valid values? I think it’s an unnecessary burden. But the topic starter on the forum mentions this.

Hmm, yes, no need. With an array default, the array|string return type holds whatever the array contains, and esc() passes non-string elements through unchanged, so nothing can throw there.