Front page | perl.perl5.porters |
Postings from May 2016
Re: [perl #128241] Deprecate /$empty_string/
Thread Previous
|
Thread Next
From:
Smylers
Date:
May 27, 2016 11:25
Subject:
Re: [perl #128241] Deprecate /$empty_string/
Message ID:
20160527112523.GC2036@stripey.com
Aristotle Pagaltzis writes:
> * 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.
Well it isn't really fix; it's more like make a change in order to keep
it working.
> Otherwise you can turn off this warning and carry on.”
Except the bug hasn't been fixed yet, so it'd make more sense to
actually fix it now, but you could change it back to what it currently
is after the following upgrade.
Most deprecation cycles are to give users advance warning of a change
that they need to make so their code will work as intended with future
versions of Perl. Given “almost certainly a bug”, a deprecation cycle
here would give users advance warning that their code will start working
as intended in the future but it doesn't do that yet so for now they
should make a temporary change (that they can later change back).
That seems like more hassle on users than a typical deprecation warning.
Or at least a different sort of hassle.
Is that really worth it for the sake of genuine uses of /$empty/, who we
don't know even exist at all?
> Although this does raise a very good point: how?
if ($pattern eq '') { // } else { /$pattern/ }
Not elegant, but it is at least possible (so long as literal //
remains), which should be sufficient for removing /$empty/.
> > > At that point, the special case is so well circumscribed that I
> > > see no real gain in excising [use of literal //] entirely,
> >
> > 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.
Fair enough.
> Have you experienced something like that? (Not rhetorical.)
I can't remember doing — but then I generate coding errors with
sufficient abundance that it outstrips my ability to remember all of
them.
> 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.
I think it's well within my bounds of ineptness to mistakenly turn a
line like this:
my $variable = some_long_function_name($with, $various, $args);
into this:
my $variable = some_long_function_name($with, $various, $args);
// 'sensible_default';
while initially failing to remove the semicolon at the end of the first
line.
Currently that yields the error message:
String found where operator expected at slash_slash line 4,
near "// 'sensible_default'"
(Missing operator before 'sensible_default'?)
syntax error at slash_slash line 5, near "// 'sensible_default'"
Execution of slash_slash aborted due to compilation errors.
Whereas using || instead of // (to get an idea of the type of error
message // could give if it didn't have two roles) gives:
syntax error at bar_bar line 5, near "||"
Execution of bar_bar aborted due to compilation errors.
The // message is a little confusing, in that it's complaining about a
missing operator at a point where there very much looks to be an
operator (but presumably Perl has interpreted as a repeated match).
Arguably the || message is less misleading, but probably not that much
more helpful to a beginner.
> 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?
I'm not proposing anything; I was simply wondering whether there are any
potential advantages in removing //, beyond ‘it's a misfeature that we
wish hadn't been introduced in the first place’.
Smylers
--
http://twitter.com/Smylers2
Thread Previous
|
Thread Next