Front page | perl.perl5.porters |
Postings from July 2013
tchrist:
> If it "works the same as", we don't need another way.
Then please go ahead and remove the code responsible for return value
of the match operator, as in C<@captures = $val =~ /â¦(â¦)â¦(â¦)â¦(â¦)â¦/>.
L<Perl 1 capture variables|http://perldoc.perl.org/
perlvar.html#Variables-related-to-regular-expressions> are good enough
for everyone! After all, Perl's motto is "there must be only one way to
do it".
> It increases the cognitive load unnecessarily for no real gain.
The real gains are:
* The match operator restores feature parity. When named captures were
added, proper return values for them were left out inadvertently, I
believe.
match op/capturing|unnamed|named
----------------------------------------
with-side effects |$1 etc.|%+
return values |yes |unnamed only!
* In the future, C<no re 'side-effects'> becomes possible which
eliminates a source of bugs. (It used to be mentioned in perltrap that
$1 etc. are not reset after a match fails, but in 5.18 it's gone for
some weird reason.) Implementing that pragma unimport blocks on having
a side-effect free way to return named captured values in the first
place.
On the other side of the scale is:
* One more flag where there are already twelve.
But this is hardly a straw that will break the camel's back. It's up to
you to back up your claim that there is a downside with concrete
evidence/examples, not just vague allusions.
Brian:
> ($d, %date) =~ m{...} # %date = %+
I don't like that because it requires a variable. This is hardly an
advantage over %+.
A simple list of return values can flow freely between chained/nested
functions, which is very perlish.
davem:
> I would prefer to see some new semantics â¦
> no idea how the details would pan out
Don't let that get in the way of the feature request under discussion.
Worse is better, and the like. I imagine this topic's feature request
is very easy to implement because the pieces are already there and
needs no further specification, whereas a different return value, with
nested structures as you said, or perhaps an L<object a la Perl6|http://
doc.perl6.org/type/Match>, would be the topic of another bug.
PS: I'm answering via RT web interface, no idea where in the p5p thread
this message ends up.
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=117447
Thread Next