On Tue, Jul 31, 2001 at 08:04:23AM -0400, "Clinton A . Pierce" <[EMAIL PROTECTED]>
wrote:
> > How about:
> > [example that didn't work as advertized, later backed up by one that did]
>
> compatibility police might object? Why? Because someone might be using sort
i don't, as sort does not behave this way currently.
> And as far as accidental use in a list/scalar context: wouldn't that be a
> problem now anyways?
again, no, since sort does not behave that way currently.
however, if it did, then this would be a very common error. how do you
force void context currently? and list context? it's possible, of course,
but it's extreme action at-a-distance.
> is). But the problem solved is similar to that of keys/values and each; and
it's similar, yes, and only being able to iterate once over a hash even
in totally different modules by different authors is an extremely nasty
thing, even if it occurs rarely in practise (it bite me about three times
in the last 6 years)
> the "smart" range operators in later perls
what are you talking about (what range operators have been added to "later
perls"?). if you mean ".." (which is very old) then I can't follow you: ..
became smarter but did not change semantics.
> avoiding having heaping piles of crap returned by an operator/function
> that can better be done in place. If we can do this without adding a
> keyword I don't see why not.
The real problem is the lack of optimization in this part of perl, not yet
another weird semantics that breaks at a distance ;)
I'd still liek the huh? operator (??) in perl, though ;)
> This feels like the Right Thing to do. It really does.
It looks like a bug to me ;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
