Would it be scope creep to consider making the proposed built-in trim() more general or customizable? There is already precedent in other languages including SQL where trim() can take an optional extra argument that defines the character set we want to trim, and if omitted it defaults to plain whitespace. That is, I propose trim() has an optional second argument that is a regular expression fragment defining a single character class, or perhaps a full on regular expression value. For example, these 2 have the same behavior: trim($str); trim($str, /\s*/); But then one could also alternately say something like this: trim($str, /\W*/); trim($str, /[abc]/); trim($str, / /); The idea is that users can decide for themselves what bounding characters are considered garbage to get rid of. I realize that keeping it simple is key because after awhile we can just say well use a regular s/// then to get what you want. The idea with my proposal is that the second argument is something simple where behavior is to strip off anything matching at the very start and very end of the string. And actually trim() should be behaving with \a and \Z or such anchors and not ^ or $ anchors as traditionally understood that treat multi-line strings special. Note that my proposal is a syntax extension so it could be ignored in the first version and added later while being backwards compatible with the simpler 1-argument version this discussion is mainly about. But maybe its worth doing in the first version. -- Darren DuncanThread Previous | Thread Next