Ok it's a simplified example, our case is more complicated, but I hope you get my point, why consistency is -technically - a win.Only from a language user point of view. For instance, in C (and its equivalent in Perl), the result of i = i++; is not defined, so it doesn't need to be consistent. This leaves compiler implementors freedom - this freedom may lead to faster code.
A more Perlish example is order in which keys() return the keys of a hash. Because the order was never defined to be consistent, a security feature (making certain DoS attacks much harder) could have been implemented between 5.8.0 and 5.8.1 (that is, in 2003), instead of having to have 5.10 being a deprecation cycle, and having to wait till 5.12 for an implementation of this fix. Of course, that's on top of the already existing benefit of keys() being faster if there's no guaranteed order.
Now, I don't want to deny that consistency is usually a good thing. I just don't agree it's always a win.
In reply to Re^5: [bugs?] perldoc perlre, \G and pos() (why consistency counts)
by JavaFan
in thread [bugs?] perldoc perlre, \G and pos()
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |