develooper Front page | perl.perl5.porters | Postings from July 2013

[perl #117447] re modifier "h" - return named captures as hash expression

Thread Next
From:
Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 via RT
Date:
July 1, 2013 15:03
Subject:
[perl #117447] re modifier "h" - return named captures as hash expression
Message ID:
rt-3.6.HEAD-2552-1372690994-116.117447-15-0@perl.org
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About