See, undefined behaviour is just that.. if you rely on it, you are submitting to surprises. Of course, your stance is a legit one, and I do think that cases like yours have to be considered; old code should not be broken lightheartedly, even if it was written with dirty practices. But I do not believe that this argument can outweigh significant reasons that favour a change.

I'm not saying that substr should be changed, rather than the current behaviour just becoming defined and documented. Whether there are any strong arguments in favour of a change in this specific instance is yet to be seen.

I do however feel that reliance on poorly documented or defined behaviour or even on outright bugs is too common a bad habit and anything that will teach people to refrain from it can only be a good thing in the long term.

After all, noone is forcing you to upgrade - Perl4, 5.0005_003 etc all still run fine. Old codebase does not have to be fixed right this instant.

I realize this is somewhat of an ivory tower opinion and that things in the realworld don't quite always work the way I would like them to. However, unless you begin somewhere and sometime, that's never going to change. And in Germany they say (roughly), a terrifying end is better than neverending terror.

In the end, I guess, it comes down to trying to find the best compromise. Legacy code should not hinder progress - but of course progress at all cost is no better either. Anyway, I think I'll quit this longwinded, meandering tangential post here before it goes much further.

In a quick response, and some clarification:

Yes, I agree that using undefined behaviour is bad style. That's an extremely valid point. I try at all costs to avoid such practices nowadays. But on the flipside, in Perl many things are undefined. Abigail-II has pointed out in the past that even $i = $i++; has undefined outcome, although all would agree that $i should not increment. The full debate started innocently here shows that there are many undefined parts to the very simplist of code. Yet most wouldn't complain such code's use.

And I definitely agree that this should be cleared up. The point I was (poorly) trying to get at that this should not be fixed now. We're going to break pretty much the entire of Perl5 when Perl6 is released. We could sort out substr's odd behaviour then, and no harm will come of it.

If this glitch was brought to attention a few years ago then I would have fully advocated a bug fix. But with it so late in the day now for Perl5, I geniunely believe the advantages of fixing this problem will be greatly outweighed by the problems it will cause. Perl5 is considered warty - and Perl6 is a fixup of those warts (with a few new groovy features added, naturally). I think it would make much more sense to just define this as it for Perl5 is in perldoc -f substr, and clean it in Perl6.

tlhf
Update: Slight typo; final $i was originally $i++;

Eh? Are you serious? Then, please tell, what is this snippet supposed to do? Shouldn't you have used the 4-argument substr() instead?

IMO, the value of an assignment is, commonly, what is assigned. This behaviour deviates from that generic rule in a very bizarre way: it does not return the new value, nor the old one. It just looks totally unreliable to me.

And this code wasn't written on a bug - it was written on undefined behaviour. As such, then any change to the perl implementation should be considered a core language change.

No way José. A change in previously undefined behaviour is called an improvement on the specification. You should never ever depend on undefined — or unspecified, behaviour. It is the prerogative of the Perl Porters to change that behaviour without any good reason.

And changing the behaviour so that in some way it would start to make sense, either in line with the rest in the language and returning the newly assigned value, or returning the replaced value, which would be inconsistent with the rest but which might be very handy; well: these make sense. To me, anyway.

I don't think your idiom is used that much.