Front page | perl.perl5.porters |
Postings from May 2016
* 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