This thread became quiet because 5.13 went into a holding pattern before 5.14.
I would like, so help me, to bring it up again.
In brief, I like the idea of __SUB__ and I think that it is a completely
reasonable name for the thing. Objections that existed at the time included:
## __SUB__ looks like other __THING__s, many of which are compile-time
## constants, but __SUB__ would not be
I think Abigail thoroughly defused this argument, and refer readers to the bug.
I think __SUB__ is an excellent name for it.
## this should be (and is) on CPAN; therefore, it need not be in core
I agree that it need not be in core, but I think it *ought* to be in core. It
is not a complex feature, but is quite useful. More importantly, it isn't
very opinionated. It provides a simple facility in about the simplest way it
could be provided. I believe this feature will improve Perl 5, and I have a
hard time envisioning a future where we lament its addition.
## this should be a module, not a core language feature
First, I don't think a programmer should have to say "use Sub::Current;" to get
this feature. I don't see that cost as being justified.
Should the implementation of __SUB__ live in an external module? Maybe! What
if we were to core Sub::Current, convince its author to provide a __SUB__
export (identical to current_sub) and then add the import of this to the :5.16
feature bundle, for example?
I'm not terribly bothered about whether the implementation belongs in a module
or the core language. My instinct would be the language, but I'm interested in
hearing from the people who are talking about doing the actual work!
I would like to land this feature in 5.16 if we can come to a general
consensus. If you think this is a mistake, please convince me.