demerphq wrote: >A bug that lives long enough is a feature? A bug that lives long enough may be troublesome to fix. In this case I'm satisfied that it's not a bug, it's Larry's design, but even if it were clearly buggy it shouldn't be changed accidentally. The behaviour is readily accessible in ordinary programs, and affects their semantics in obvious ways. On simple stability grounds, it's worth having test cases to enforce that we don't change this behaviour without specific intent to do so. If you want to change it, presumably you wouldn't want to make foo($x{bla}) eager, because that would be creating unintended hash entries all over where the parameter is taken by value. Presumably you'd want to make \$x{bla} lazy. I don't have a clear idea of what impact that would have. Maybe you should do a CPAN smoke of that version of the core (it's a very easy change to make), though obviously changes of the underlying language aren't really what CPAN module test suites are looking for. Presumably we'd want a deprecation cycle for the change, or a feature flag, and that seems an awful lot of fuss to go to for a design wart of such low wartiness. If all you want is for a lazy version of \$x{bla} to be available, that could be easily implemented by an XS module. (Alas, "sub lazy_lv { \$_[0] }" doesn't do it: it becomes eager.) -zeframThread Previous | Thread Next