> > RFC138: Eliminate =~ operator.
> 
> > RFC164: Replace =~, !~, m//, and s/// with match() and subst()
> 
> Which I could see unifying. I'd ask people to wait until v2 of RFC 164
> comes up. It may well include everything from RFC 138 already.

Hm. Larry didn't really like anything that would reverse the order of
the pattern and the expression to be matched against, and I think I
agree at least that it should always be possible to put the direct
object at the beginning, preferably in a way usable by more than just
regex-related operators. I'm not so convinced that that is always the
best order, but weakening RFC138 to propose only an alternative would
force me to rename it. So I'll probably just withdraw RFC138 and ponder
whether to submit another one with a different name that proposes
something similar as an option to =~ or whatever it becomes.

My problem with RFC138 disappearing into RFC164 is that I strongly
dislike the idea of losing // and having to use the five-letter match()
all the time. So Nate is welcome to any or all of the ideas in RFC138,
but I don't think RFC164 will ever be something that fills the need I
was addressing with RFC138. I gotta have my perl -lne 'print $1 if
/count=(\d+)/'.

($foo = $bar) =~ s/x/y/; will never make much sense to me. But I can
live with it.

Reply via email to