* Smylers <Smylers@stripey.com> [2016-05-27 11:21]: > Aristotle Pagaltzis writes: > > Personally: > > > > • I agree /$empty/ should be deprecated. > > > > • I oppose changing its behaviour without a deprecation cycle. > > “Warning: We've found a bug in your code. Please fix it now, otherwise > a future version of Perl will automatically fix it for you.” “Warning: we’ve found behaviour in your code that is almost certainly a bug. If by any chance it is not, then you need to fix your code now. Otherwise you can turn off this warning and carry on.” Although this does raise a very good point: how? In previous threads about this I proposed a ${^LAST_MATCHED_PATTERN} (or whatever its name) which would be a qr object. (At which point it becomes conceivable to eventually remove the special case entirely, since there is another exactly equivalent way of getting it. But I still don’t think it would be a worthwhile gain.) > > At that point, the special case is so well circumscribed that I see > > no real gain in excising [use of literal //] entirely, however > > ancient-Unix-warty it may be. > > Would it have advantages for users of the identically spelt // > defined-or operator? Specifically, are there circumstances where > somebody who makes a mistake while trying to use defined-or could get > an error message but at the moment gets mysterious repeat-match > behaviour? Or does get an error message, but a suboptimal one? a) Just taking your questions at face value – I don’t think so. Have you experienced something like that? (Not rhetorical.) I cannot say that I have, myself. I am not aware of any context where // is ambiguous as to whether it means defined-or or empty match. All of the ways I can think of to accidentally get a match when one wanted a defined-or boil down to forgetting to type the variable in an expression, which is a type of mistake I believe I have not made even once in my entire programming life. Hence, presumably, why I’ve never run into such a case. b) Your questions seem moot in the first place, though. Are you proposing to make // not even parse as a match literal at all any more? Then consider what that would do to `$foo =~ //`. The error would be something like “operand missing”. That is the opposite of an improvement. I would oppose that proposal. If you merely wanted to remove the special case behaviour entirely, that expression would still have to parse as an empty match literal and only then – maybe – warn that that is a useless operation. So the fact that // means a match literal in some contexts and defined-or in others would still remain, which means in that case your questions are based on a faulty premise. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next