Front page | perl.perl5.porters |
Postings from February 2018
Sawyer X wrote: >What I am reading here is implying that cosmetic changes are >meaningless. That's not my position. Cosmetic issues are of lower importance than functionality and coherence, but are not entirely devoid of value. >Furthermore, one could also argue that calling return from a signature >serves little purpose and is also a cosmetic difference No, that's not cosmetic, that's a difference in functionality. One might still argue that it serves little purpose, of course. But that argument is about behaviour, not aesthetics. > Is there any value in returning from a signature Some, yes. Returning from a default value expression can be a convenient way to make a subroutine do different jobs depending on the arguments supplied to it. In non-signature-using Perl it's common enough to see constructs along the lines of "defined $foo or return $blah". Compared to putting this logic in the body block after the signature, having it in the signature will at times be beneficial in a number of ways. Firstly, it is likely to group related concerns. If there are other non-trivial default expressions then it may also be important to return before executing the next default expression, and putting all of that logic into the body block would involve quite a lot more verbiage. If default value expressions have to be moved into the body block then we also run into the issue of parameter predicates: currently they're not available as part of the signature system, and some people are arguing against them ever being so, so this might force ugly use of @_ (or incorrect use of defined()) alongside the signature. There's also more value than this in permitting returning from a signature. Perl benefits from the popular pardigm of interchangeability of expressions, that any expression can go anywhere that an expression is permitted. A return expression is a type of expression, and it doesn't take any verbiage to explain, or neurons to remember, that it is permitted inside a while() condition, or in a sub parameter expression, or in any other particular place that takes an expression. But if it's not permitted in a default value expression in a signature, that's an exception to the general rule, which does need to be specially explained in the documentation, and does need to be specially remembered by users, to explain why their program doesn't work on the rare occasion that the nature of a subroutine leads them to put this type of expression in that type of expression slot. >It's just a wrong place to start the discussion from, IMHO. What is? >Have we ever explored this class of functionality? Where is the >likeliness coming from? The potential that would be lost is to have attributes affect the compilation of a subroutine's body code. The :lvalue attribute is an instance of that kind of functionality. Another likely instance of it came up in one of the threads about @_ suppression. The general concept being discussed was that we're going to make direct use of @_ obsolete, through signatures and maybe other features, so it would be nice for performance if we could suppress the construction of the dynamic @_ on subs that don't need it. The starting point for the discussion was the idea of tying this suppression to signature syntax per se, either to its enablement or to actual signatures, but we wisely decided against that. Among control mechanisms discussed was the fairly obvious possibility of a subroutine attribute offering explicit control of @_ setup for a specific subroutine. This in itself doesn't pose an ordering problem. Another aspect of @_ suppression being discussed was what should happen to direct references to @_ that appear in the body of an @_-suppressed subroutine, and one of the main options was that this should be an error. For it to be an error requires that the @_ status of a subroutine be known before any of its body code is compiled, and in the absence of signatures this would be entirely compatible with attribute control. But with signatures coming before attributes, some body code that might refer to @_ would be compiled before the @_ status of the subroutine is determined. Any option for @_ suppression that affects how direct references to @_ compile is incompatible with control by an attribute if the attribute would appear after a signature. There's quite a problem here in that it looks somewhat inevitable for there to be some kind of per-sub control over @_ suppression. Lexical flags can set defaults, but there's always going to be the occasional exception. What we find here is that if subroutine attributes preceding the body didn't exist then it would be necessary to invent them. Currently we have them, but if they are abolished again by moving signatures in front of attributes again then this would create some design pressure to invent something new that does a similar job to attributes but appears before a signature. -zeframThread Previous | Thread Next