As a reminder, after a lot of discussion, there was broad agreement that we should add the capability for trimming a string, and we should keep it simple: trim whitespace from both ends of the string, with no parameterisation. Here "whitespace" means [:space:], so consistent Unicode semantics, whatever the internal encoding of the string.
But there was disagreement on whether it should trim in place, or return the trimmed string. Maybe we should have two functions: trim() to edit in place, and trimmed() to return the trimmed string. Rik, Sawyer, and Neil were all fans of the in-place edit.
After lots of discussion on github and p5p, the steering council also solicited input from people with a lot of experience training people and/or writing books to explain Perl.
The end result of all of that is:
• We think we should add a single function to Perl.
• It should return the trimmed string.
• It should be called "trimmed", not "trim".
This is not a mandate, but it is our recommendation.
What convinced us on the naming issue was an example from Tom Christiansen of a large company that had a similar internal discussion, and found that people were confused over how they expected it to work, until they changed the name from "trim" to "trimmed". This also fits in with one of Larry's original desires, that Perl be a readable language. The function returns a trimmed version of its input:
$x = trimmed $y; # "x is a trimmed version of y"
We think that "trim" would have been the right name for editing in place:
trim $x;
There are only two distributions on CPAN that define a function called "trimmed", so we suspect that this will clash with less code in the wild. There are plenty of distributions that define a trim(), but not all of them perform the function we're talking about here.
It may be tempting to claim that if we called it "trim" rather than "trimmed", then it "would just work" for the majority of people with an existing trim function (whether imported from CPAN or home-brewed). But whatever a new builtin is called, existing code would not use it by default, so everyone would have to make edits to enable it, no matter what name we give it.
There's a related topic of namespaces for functions like this. We're deliberately not addressing that here, as we suspect it will fall out of the broader review of text/string processing capabilities, which we want completed before 5.36 (i.e. before trimmed would be included in a stable release anyway).
We're now interested to hear what p5p thinks of this.
Neil, Rik, Nick
But there was disagreement on whether it should trim in place, or return the trimmed string. Maybe we should have two functions: trim() to edit in place, and trimmed() to return the trimmed string. Rik, Sawyer, and Neil were all fans of the in-place edit.
After lots of discussion on github and p5p, the steering council also solicited input from people with a lot of experience training people and/or writing books to explain Perl.
The end result of all of that is:
• We think we should add a single function to Perl.
• It should return the trimmed string.
• It should be called "trimmed", not "trim".
This is not a mandate, but it is our recommendation.
What convinced us on the naming issue was an example from Tom Christiansen of a large company that had a similar internal discussion, and found that people were confused over how they expected it to work, until they changed the name from "trim" to "trimmed". This also fits in with one of Larry's original desires, that Perl be a readable language. The function returns a trimmed version of its input:
$x = trimmed $y; # "x is a trimmed version of y"
We think that "trim" would have been the right name for editing in place:
trim $x;
There are only two distributions on CPAN that define a function called "trimmed", so we suspect that this will clash with less code in the wild. There are plenty of distributions that define a trim(), but not all of them perform the function we're talking about here.
It may be tempting to claim that if we called it "trim" rather than "trimmed", then it "would just work" for the majority of people with an existing trim function (whether imported from CPAN or home-brewed). But whatever a new builtin is called, existing code would not use it by default, so everyone would have to make edits to enable it, no matter what name we give it.
There's a related topic of namespaces for functions like this. We're deliberately not addressing that here, as we suspect it will fall out of the broader review of text/string processing capabilities, which we want completed before 5.36 (i.e. before trimmed would be included in a stable release anyway).
We're now interested to hear what p5p thinks of this.
Neil, Rik, Nick