Mark-Jason Dominus wrote:
>
> It seems to me that there are at least two important things missing
> from this proposal.
>
> 1. There is no substantive rationale presented for why the change
>would be desirable.
>
> The only reasons you put forth are:
>
> * The syntax is ugly and unintuit
Larry Wall wrote:
>
> The problem here is that I think =~ does one thing right--it brings the
> "topic" out front. Hiding the variable to be modified clear out at the
> end of a big regex is not going to be a winner. It's bad enough that
> the /x modifier comes at the end.
>
> More generally,
Nathan Wiger wrote:
>
> > : =~ has no real world equivalent, and in fact I don't know how to
> > : pronounce it in English so that $x =~ /a/ makes sense.
> >
> > Yes, that's all pretty much on the mark.
>
> Not true, IMO. In math, =~ is used to indicate "rough equivalence".
> (Actually, the ~ go
> > 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 re
Tom Christiansen wrote:
>
> >($foo = $bar) =~ s/x/y/; will never make much sense to me.
>
> What about these, which are much the same thing in that they all
> use the lvaluability of assignment:
>
> chomp($line = );
> ($foo = $bar) += 10;
> ($foo += 3) *= 2;
> func($diddle_me =
