develooper Front page | perl.perl5.porters | Postings from February 2021

Re: De-experimentalising "signatures"

Thread Previous | Thread Next
February 15, 2021 18:42
Re: De-experimentalising "signatures"
Message ID:
Dave Mitchell <> writes:

> On Mon, Feb 15, 2021 at 01:26:43PM +0000, Dagfinn Ilmari Mannsåker wrote:
>> Even if this were to happen in the next release cycle, I think it should
>> be done as a separate feature (possibly a default-enabled feature one
>> can opt out of, like multidimensional and indirect). Even though the
>> signatures feature is still experimental, lots of people have started
>> using it due to the exceptionally long time it's been stable (as in not
>> changing, even if not officially declared such).
> I don't like that at all. Also, It would be be hard to efficiently support
> both options - the signature processing ops would have to handle
> retrieving code from either the stack of @_.

If it's too expensive to check the hints hash in the signature
processing ops, we could set a flag directly on them, or if even that is
too much, we could have separate OP_ARG*_NOSNAIL variants, and decide at
sub compile time which ones to emit.

> Also there are a bunch of edge cases if @_ is visible: what happens if
> code is executed halfway through processing signatures (such as
> constraints) which modifies @_? Is this seen by later parameters? When
> we optimise things are default expressions then skipped? Etc etc. It
> becomes a bit of a can of worms.

The current documentation (
quite clearly specifies the evaluation order and side effects (and a
quick test reveals that manipulating @_ in the default expression of an
argument is visible to subsequent default expressios).

But there's nothing stopping us changing all of that in the scope of `no
feature 'snail';`, as long as it's something that authors explicitly opt
in to in the lexical scope in which the sub was compiled (it can of
course be disabled by default by a future versioned feature bundle).

- ilmari
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."                              -- Skud's Meta-Law

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About