develooper Front page | perl.perl5.porters | Postings from May 2016

Re: [perl #128241] Deprecate /$empty_string/

Thread Previous | Thread Next
Aristotle Pagaltzis
May 27, 2016 10:21
Re: [perl #128241] Deprecate /$empty_string/
Message ID:
* Smylers <> [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.

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About