On Wed, 2 Nov 2005, Rob Kinyon wrote:
I think the difference comes from the Principle of Least Surprise. The various operators being discussed in this thread are all operators which are in languages that have common use - C, C++, Java, the .Net stack, etc. Regexen and the various built-ins are generally considered to be Perl-specific, so if they're weird, this is just a Perl-ism. The PoLS doesn't apply.
I still don't buy the argument. At least in principle PoLS does apply for a newbie may be surprised to know that certain operators act implicitly on $_ and certain other don't.
And yes: there are lots of languages having (e.g.) a ++ operator, mostly "derived" from C. But Perl's C<++> already allows an extended syntax wrt that of those other languages, that is: I'm not really sure, but I don't think that in C you can do (the equivalent of) C<($u*=5)++> - not that you need it that often, granted! But it is "backwards" compatible with the "standard" usage.
Now letting aside other reasons why the proposal should not be accepted, if it where, it would not be disruptive of current behavior. You could have $_++ *and* bare ++. And newbies learn early enough that $_ is the implicit topicalizer in Perl; moreover ++ will still look intuitively enough like the incrementing op. So I think it won't be that difficult for them to understand what's going on, the biggest remaining doubt being whether it's ++$_ or $_++. But that's just, say, a clpmisc or PM post away and anyway it will be in the docs (no, I know it won't, but that's not the point...)
Yes, from a consistency point of view, ALL operators should default to $_ or some other sensible item ($*STDIN for <>, etc). However, the PoLS does need to guide our decisions.
Hmmm, it's so difficult for me to keep up with P6, but I *think* <> has been phased out in favour of prefix unary C<=>.
Michele -- you look around what do you see? I'll tell you what I see is a world belonging to me - Pennywise, "Living For Today".
