develooper Front page | perl.perl5.porters | Postings from December 2012

Re: RFC: Removing several undocumented functions from the Perl core

Thread Previous | Thread Next
Karl Williamson
December 3, 2012 15:18
Re: RFC: Removing several undocumented functions from the Perl core
Message ID:
On 12/03/2012 02:55 AM, Nicholas Clark wrote:
> On Tue, Nov 27, 2012 at 07:46:26PM -0600, Steve Peters wrote:
>> On Tue, Nov 27, 2012 at 4:31 PM, Karl Williamson <>wrote:
>>> There are several functions that are no longer used in the Perl core that
>>> could be removed, along with their associated interpreter variables.  These
>>> are
>>>   is_uni_idfirst_lc
>>>   is_utf8_idfirst
>>>   is_utf8_xidfirst
>>>   is_utf8_idcont
> [is_uni_idfirst, is_utf8_xidcont, is_utf8_mark]
>>> cpan grep with
>>> -file:"ppport\.h|PPPort\.pm" is_(uni|utf8)_(mark|x?id(**first|cont))
>>> returned 16 results.  None of them look like they are actually using these
>>> functions except as compatibility measures.
>>> I propose removing them.
>> Removing them is decently risky.  I can't say we exactly know what the
>> blackpan is doing with them.  Things that are deprecated in the API are
>> supposed to be moved to mathoms.c where they can be optimized out with a
>> -DNO_MATHOMS when compiling.
> That's true enough, but there have been some functions marked as part of the
> API that we've actually removed. IIRC they
> a) probably never should have been marked as "API"
> b) weren't used by anything we could find on CPAN
> c) were useless, counterproductive, or downright dangerous
> We removed them by marking them as deprecated in embed.fnc (which at least
> for gcc we can flag them as "deprecated" in the headers and it warns)
> and then after a major release, zapping them.
> These functions seem to be pretty similar.
> I think we should do the same:
> a) mark them as deprecated
> b) release 5.18.0
> c) see if anyone squeals
> d) remove them
> e) release 5.20.0
> Nicholas Clark

I had come to the same conclusion yesterday, and started working on a 
patch to do so.  I thought our policies would actually dictate, though, 
that we give 2 major cycles of deprecation, thus removing in 5.22.

These functions, and a number of others really should not have been part 
of the public API.  The similar ones that are still used are adjuncts to 
macros in handy.h, called for inputs that the macro can't handle itself. 
  But because they are stand-alone also, the function has to have logic 
in it as if called not by the macro.  This typically means that the same 
tests have to be repeated, at the cost of efficiency.

The problem, unless I don't understand things, is that in order for the 
macros to be globally available, the functions they call need to be 
declared in embed.fnc as "A" which I believe (and correct me if I'm 
wrong) is the only way for the function to be accessible outside 
PERL_CORE/PERL_EXT, and that means the function is considered to be part 
of the public API.  I did change this some time ago so that an 
undocumented "A" function that was marked with "M" for "may change", is 
not listed at all in perlapi.  I have a smoke going that includes a 
patch to do this for all the handy.h adjunct functions.

Perhaps people familiar with the other functions that are listed in 
perlapi as undocumented could check to see if they should be removed 
from the public list by marking them as "M".

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