On Wed, Mar 31, 2021 at 11:12 AM <neilb@neilb.org> wrote: > In your research did you find out if people implementing trim() as a sub > do it in-place or as a return value? That seems to be hotly debated right > now. > > > Hereâs a bit of the CPAN story. > > - Text::Trim and String::Trim both provide a trim that works both ways. > - String::Util, Mojo::Util, Data::Munge, and String::Trim::More > provide non-mutating trim only > - String::Strip provides various trim functions that edit in place > - There are other trim functions and methods that do other things > (e.g. HTML::Trim's trim()) > - Plenty of distributions define their own trim. Some edit in place, > the majority don't (though some effectively are, because they then write $x > = trim($x)). > > Total usage of all of these by other distributions on CPAN is very low, > compared to the number of distributions using s/// directly. > > Looking at Text::Trim, of the other CPAN distributions use'ing it: > > - 4 import it but don't use it > - 14 use trim purely functionally > - 7 use it to effectively edit in place: $x = trim($x). > - 1 explicitly uses the edit-in-place approach > > As noted previously, about 7500 dists do it in-place using s///. > > What we're talking about is providing a built-in to replace a widely used > idiom. The built-in will (a) do what you meant, (b) be faster, and (c) be > easier to remember. > Just a slight addendum to this and Ben's excellent detail of the situation: the "effectively in-place" form can be (and I believe may already be, in the PR) optimized as a built-in to an actual in-place operation even when you don't write it as one. -DanThread Previous | Thread Next