Open wchristian opened 9 years ago
perl -we -MIO::All "$SIG{__WARN__}=1; eval q|$a<io(q[.]);1|"
@wchristian, a few problems with that repro attempt:
1) putting -we before -MIO::All doesn't work at all! :) 2) putting $SIG in double quotes won't work on a POSIX shell. It is a shell var that will just disappear (or worse). 3) Using . as the io argument results in:
Undefined behavior for overloaded IO::All operation: 'dir > scalar' at (eval 1) line 1.
This is a good repro:
$ echo OHAI > x
$ perl -MIO::All -wE '$SIG{__WARN__}=1; eval q{$a < io(q{x}); say $a}'
Useless use of numeric lt (<) in void context at (eval 1) line 1.
OHAI
Use no warnings qw/…/
for that?
Instead of removing it, it should be localized to just where it's needed.
The problem is, "where it's needed" is in the user's code, where they use such an operator, not in the code of IO::All. The only recourse I can see that will avoid messing with the global program state is to remove the overloads on '>' and '<', or to accept that void warnings will occur whenever they're used.
@Grinnz I seem to remember @ingydotnet having pondered cutting out the overloading entirely, and moving it into a module that can be loaded additionally if the user wishes it to occur. I do however not know if there's a ticket for that.
Cursory skim of the ticket pool didn't surface one.
This bit me in a testing environment today by a bunch of "useless use of * in void context" warnings not being caught where they should have been, because IO::All had been loaded first and suppressed all these warnings. Please could we move the operator overloading into a separate module that is only used when people really want it? Otherwise, the only thing I can do is stop using IO::All and patch everything in my dependency tree to stop using it as well.
Turning of overloading by default is a good idea. Need some tuits. Let's discuss on #io-all
Right now IO::All has a
$SIG{__WARN__}
handler to filter out overload-related compile time syntax warnings. This is vulnerable to SIG collisions. It should be removed entirely, and handling those be left to the user, or maybe handled via lexically unsetting those warnings. (Something @shadowcat-mst mentioned and i'm not sure about how it's done.)