On Sun, Mar 18, 2001 at 04:19:47PM +0000, nick@ing-simmons.net wrote: > <abigail@foad.org> writes: > >On Mon, Mar 12, 2001 at 11:59:24AM +0000, Nick Ing-Simmons wrote: > >> > > >> >Is this a bug or not? > >> > >> It cannot be - changing either is bound to break something. > >> > >> >Is there a way to fix this? > >> > >> Not without breaking scripts which rely on the behaviour. > > > > > >I've a bit of a problem with that reasoning. That would mean you can > >never, ever fix a bug, because there's bound to break something. > > It is a way of defining what can be a bug. If the behaviour is useful > and likely to be used it isn't a bug it is a feature. How does p5p define "useful" and "likely to be used"? > > > print 'foo'=~/(.*)/ && $1, 'bar'=~/(.*)/ && $1, "\n"; > > > print 'foo'=~/(.*)/ && "$1", 'bar'=~/(.*)/ && "$1", "\n"; > > In this case I assume that there is an existing body > of code that expects $1 to to be the last value matched, so that making a copy > as it is passed to print (or subs in general) would break that code at least. > And the second line shows that there is an easy way to get the copy if that > is what you want. In the case of $1, stringifying it doesn't harm it. But the same behaviour happens with all scalar variables. Including references. Whose stringification isn't reversable. As for this specific case, I don't find it at all reasonable to assume there's a body of code following it, assuming $1 to be anything. However, that's irrelevant, as it's not the last $1 that's causing the problem - it's the first $1 which isn't what one would expect it to be. It boils down to, should && and || return aliases, or values? If it's useful and likely to be used, could you point out some code that's using the fact && returns an alias, and would break if it returns a value? Furthermore, if && is supposed to return an alias, shouldn't the following at least parse, and either assign 1 to $bar or give a runtime error? ($foo && $bar) = 1; AbigailThread Previous