> You could "kinda" make it look like a "real" function, as has occasionally > been suggested: > > match(STRING, PATTERN, FLAGS) > > But before that gets too much support, that has several problems. > First, unless you have rather clever new context coercion prototypes > of type regex (which would let us define split(), too, though) I actually half-heartedly suggested this last night on a considerable amount of beer :-), but ran into the same issues you mention. I do think it's worth considering if we're dead-set on losing =~. It might also be worth looking at Ed Mill's suggestion of putting the incoming string all the way to the right. Then we could make it look like split and join: match /pattern/flags, $string subst /pattern/newpattern/flags, $string The more I look at that, the more I like it. Very consistent with split and join. You can now potentially match on @multiple_strings too. Something else I threw out that maybe people didn't see was just using =, ==, and !=: $x == m/stuff/; # == replaces =~ $x != m/stuff/; # != replaces !~ $r = m/stuff/; # same as current $r = ($x == m/stuff/); # == replaces =~ This would require redoing/overloading these, but that's an internals quesion methinks. The last alternative is to come up with a matching operator: ma - "matches" (like eq) nm - "not matches" (like ne) $x ma /stuff/; $x nm /stuff/; But I think door #1 or #2 is better. I actually think I like the function form alot. -Nate
- Re: RFC 135 (v2) Require explicit m on matches, even wit... Tom Christiansen
- Re: RFC 135 (v2) Require explicit m on matches, eve... John Porter
- Re: RFC 135 (v2) Require explicit m on matches, eve... Peter Scott
- Re: RFC 135 (v2) Require explicit m on matches, eve... Tom Christiansen
- Re: RFC 135 (v2) Require explicit m on matches, eve... Nathan Torkington
- Re: RFC 135 (v2) Require explicit m on matches, eve... Nathan Torkington
- Re: RFC 135 (v2) Require explicit m on matches, eve... Bart Lateur
- Re: RFC 135 (v2) Require explicit m on matches, eve... Nathan Torkington
- Re: RFC 135 (v2) Require explicit m on matches, eve... Tom Christiansen
- Re: RFC 135 (v2) Require explicit m on matches, eve... Casey R. Tweten
- Re: RFC 135 (v2) Require explicit m on matches, eve... Nathan Wiger
- Re: RFC 135 (v2) Require explicit m on matches, eve... John Porter
- Re: RFC 135 (v2) Require explicit m on matches, eve... Bart Lateur
- Re: RFC 135 (v2) Require explicit m on matches, eve... John Porter
- New match and subst replacements for =~ and !~ (was... Nathan Wiger
- Re: New match and subst replacements for =~ and !~ ... Mark Senn
- Re: New match and subst replacements for =~ and !~ ... Randy J. Ray
- Re: New match and subst replacements for =~ and !~ ... Nathan Wiger
- Re: New match and subst replacements for =~ and !~ ... Bart Lateur
- Re: RFC 135 (v2) Require explicit m on matches, eve... Damian Conway
- Re: RFC 135 (v2) Require explicit m on matches, eve... Bart Lateur