builtin::trim() - Only warn about being experimental once

[wolfsage]

ck_builtin_func1() already handles the warning for us, so we don't need to repeat it in our function.

[leonerd]

Ah, but the opchecker only runs at sites that are compiletime determined to be trim. It's possible to defeat that check:

$ bleadperl -E 'my $func = \&builtin::trim; say $func->(" hello world  ")'
Built-in function 'builtin::trim' is experimental at -e line 1.
hello world

If you remove the line from the XSUB then this would no longer be printed.

[tonycoz]

Even just the & call:

tony@venus:.../git/perl5$ git describe
v5.37.3-320-g2fc9215704
tony@venus:.../git/perl5$ ./perl -Ilib -E 'builtin::trim("foo")'
Built-in function 'builtin::trim' is experimental at -e line 1.
tony@venus:.../git/perl5$ ./perl -Ilib -E '&builtin::trim("foo")'
tony@venus:.../git/perl5$

or if you want to get silly:

# strict safe symbolic reference
tony@venus:.../git/perl5$ ./perl -Ilib -Mstrict -E 'say *{$::{"builtin::"}{"trim"}}{CODE}->("  foo")'
foo
tony@venus:.../git/perl5$

I don't see a way to catch all of these at compile time, but the \&builtin::trim and &builtin::trim() versions could be caught with op checkers for srefgen and entersub.

I doubt that's worth the trouble though.

[wolfsage]

We discussed on IRC a bit and we think the best option is have to lightweight XS methods that call a shared method - one used by the op checker which will not warn, and one used normally when the opchecker is not involved.

[jkeenan]

We discussed on IRC a bit and we think the best option is have to lightweight XS methods that call a shared method - one used by the op checker which will not warn, and one used normally when the opchecker is not involved.

While this p.r. got one approval (from @tonycoz), subsequent discussion indicated people have doubts. @wolfsage, do you want to pursue this p.r.?

[jkeenan]

We discussed on IRC a bit and we think the best option is have to lightweight XS methods that call a shared method - one used by the op checker which will not warn, and one used normally when the opchecker is not involved.

While this p.r. got one approval (from @tonycoz), subsequent discussion indicated people have doubts. @wolfsage, do you want to pursue this p.r.?

@wolfsage, do you want to pursue this p.r.? It has languished since November.

[wolfsage]

We discussed on IRC a bit and we think the best option is have to lightweight XS methods that call a shared method - one used by the op checker which will not warn, and one used normally when the opchecker is not involved.

While this p.r. got one approval (from @tonycoz), subsequent discussion indicated people have doubts. @wolfsage, do you want to pursue this p.r.?

@wolfsage, do you want to pursue this p.r.? It has languished since November.

I do not see me having any time for this in the near future. It should probably still be "fixed" but is a fairly minor issue. Really this PR should be an Issue at this point...

[demerphq]

@wolfsage want me to pick this up for you?

[wolfsage]

@demerphq Sure!