There has been a lot of discussion about trim(), here on p5p[1], on a github issue[2], and a pull request[3] with a proposed implementation. We've started this new thread to present a concise summary and ask people to specify their preferred option. Please do not start discussion on this thread.
We would particularly like core team members to reply.
Summary of the picture
• Looking at CPAN, when people have wanted to trim a variable, they've been massively more likely to just use a regexp than either write their own function or use one from CPAN. But in plenty of cases they get it wrong.
• There are CPAN modules offering both edit-in-place and return-trimmed-string. The latter are more widely used, though a third of those uses are of the form $_ = trim($_).
• When people roll their own trim() function, they're more likely to return the mutated string, but it's not 100%.
Brief pitch for the options:
• Return value: when people write a trim() function this is what they tend to write; can be composed and used in a map; there are plenty of other string built-ins that return a mutated copy.
• Edit-in-place: most people are editing in place to trim a variable; similar to chomp and s/// which both edit in-place; would take an lvalue so you can write trim(my $x = …);
I think we're all agreed on these points:
• There's evidence on CPAN that this is worth adding to the language.
• Trim should remove whitespace on both ends of the string.
• Trim Unicode \s – don't support an argument for specifying what to trim.
• A single function that works both ways, depending on context, is not a good solution.
What do you think we should do?
1. Two separate but similarly named functions. Names TBD.
2. One trim() function that returns the trimmed string
3. One trim() function that edits in place
4. Leave it to CPAN
5. Given we've missed the 5.34 boat, perform a wider review of text processing gaps in Perl, possibly resulting in a broader proposal, which might change how we think about trim.
[1] https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259427.html
[2] https://github.com/Perl/perl5/issues/17952
[3] https://github.com/Perl/perl5/pull/17999
We would particularly like core team members to reply.
Summary of the picture
• Looking at CPAN, when people have wanted to trim a variable, they've been massively more likely to just use a regexp than either write their own function or use one from CPAN. But in plenty of cases they get it wrong.
• There are CPAN modules offering both edit-in-place and return-trimmed-string. The latter are more widely used, though a third of those uses are of the form $_ = trim($_).
• When people roll their own trim() function, they're more likely to return the mutated string, but it's not 100%.
Brief pitch for the options:
• Return value: when people write a trim() function this is what they tend to write; can be composed and used in a map; there are plenty of other string built-ins that return a mutated copy.
• Edit-in-place: most people are editing in place to trim a variable; similar to chomp and s/// which both edit in-place; would take an lvalue so you can write trim(my $x = …);
I think we're all agreed on these points:
• There's evidence on CPAN that this is worth adding to the language.
• Trim should remove whitespace on both ends of the string.
• Trim Unicode \s – don't support an argument for specifying what to trim.
• A single function that works both ways, depending on context, is not a good solution.
What do you think we should do?
1. Two separate but similarly named functions. Names TBD.
2. One trim() function that returns the trimmed string
3. One trim() function that edits in place
4. Leave it to CPAN
5. Given we've missed the 5.34 boat, perform a wider review of text processing gaps in Perl, possibly resulting in a broader proposal, which might change how we think about trim.
[1] https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259427.html
[2] https://github.com/Perl/perl5/issues/17952
[3] https://github.com/Perl/perl5/pull/17999