It doesn't make Perl's management look efficient
It's very little to do with management (efficient or otherwise), and mainly to do with lack of manpower. Specifically there's a whole bunch of stuff I am aware of that needs pinning down and then implementing, before signatures can become non-experimental.
As one example, consider the behaviour of @_ within the body of a signatured sub. Should it still contain the full argument list (but then you incur the cost of setting up and restoring @_ for each call), or be empty (you still have a setup/restore cost), or be untouched and still have the value it had before the current function was called? Should accessing / modifying @_ trigger a warning, or even be fatal? What happens when a function is called via the argless &foo;
mechanism - for each of the combinations of caller/callee being an ordinary/signatured sub? If @_ isn't populated, how can the sub tell whether a particular arg got passed a real undef value or no value? Should the behaviour of @_ be controllable? If so, should that be via a pragma or some new syntax within the signature? (Those are all rhetorical questions - I don't want to get into a debate about signature semantics here.)
Until all that has been decided and implemented, we don't know how @_ will change, so can't mark it as non-experimental.
Deciding and implementing all that is currently in my balliwick, and I only have so much time.
Dave.
| [reply] |
I agree it's complicated and respect your wish to not discuss semantics here.
But that's not what I meant with management.
Function signature would have a bigger positiv impact on beginners than our declarations or defined-or // operators (to name some very popular added features not talking about smart match ~~ )
It doesn't seem like P5P (or whoever else has the final word) does strategical planning.
I'm not attacking you or asking you to invest more.
I'm just stating a lack of market thinking.
| [reply]
[d/l]
[select] |
| [reply] |
