Revert "open: only treat literal undef as special"

[ap]

This reverts commit 471c834 (i.e. #22465) but also adds a test which the reverted code would not pass and a perldelta item.

Checks based on the syntax tree of the call site fix #22385 for some number of common cases, but not all of them, at the cost of breaking the ability of APIs that wrap open to expose its anonymous file mode. A notable example of such an API is autodie.

The current PSC is unanimous in disliking language features conditional on the exact shape of the syntax tree, as they make the language more brittle. The reported issue is a problem, but this attempt to fix is not a good approach long-term, especially given how many edge cases it leaves unsolved.

---

• This set of changes requires a perldelta entry, and it is included.

[mauke]

at the cost of breaking the ability of APIs that wrap open to expose its anonymous file mode

That is not quite true. Wrappers indeed could not replicate the "literal undef only" behavior of open, but they could keep their old behavior of triggering anonymous file mode in more cases¹. So in edge cases autodie would have stayed compatible with previous versions of autodie, but not with CORE::open.

---

¹ Description of "old behavior" omitted because I don't think such a description is possible. Anonymous file mode has no semantics. :-( Better fixes very much welcome.

[ap]

Description of "old behavior" omitted because I don't think such a description is possible. Anonymous file mode has no semantics. :-( Better fixes very much welcome.

Frankly I think the API surface is just misshapen. It’s a cute idea to say “an undefined filename means the file is anonymous” but it makes a crappy API. If we are going to provide this functionality through open itself then the signal should be a different value than undef, one which doesn’t have other meanings attached to it (e.g. a reference that is blessed into a special package just for this, or an empty string with a special magic flag returned by some kind of builtin::tempfile function).

Unfortunately that means changing API, and I don’t know how feasible that is nowadays, given that a lot of Perl code is not going to receive maintenance. (I suppose maybe we could feature-gate this with a negative feature, so that in future you get something saner under a recent use VERSION, and then for old code perl can just expose the exact same behavior it always has.)

FWIW I appreciate your attempt to fix the API as is. It’s just I don’t think costs and benefits add up with this approach.