To be clear, I am content with the status quo, but it seems that there is an effort afoot to remove bareword filehandles entirely, and I present this proposal as an alternative change that will cause less breakage than the previously proposed change of removing the feature entirely. I do not think that I can get indefinite continuation of the status quo, so I make this proposal as a "next best thing" from my perspective.
You raise a good point that existing code expects to be able to pass a reference to a bareword filehandle with \*FH. The parser could still accept that syntax and consider it another form of {I/O}FH, but the \* would no longer be required. This would allow passing filehandles as arguments to I/O builtins and user subroutines equivalently.
I am not saying that my $FH should stop working, only that "plain" filehandles should become equivalent to that in preference to being removed entirely. I also see some opportunities to simplify the interpreter guts along the way, which is a suitable justification for change, especially when efforts are made to maximize compatibility with existing code that does not use my $FH, as this proposal seeks. Since you mentioned that even package was not being considered at your workplace before you started, how likely are there to be other places where my $FH is still entirely unknown? How much code will they have?
In reply to Re^8: On Backwards Compatibility and Bareword Filehandles
by jcb
in thread On Backwards Compatibility and Bareword Filehandles
by jcb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |