Le jeu. 25 nov. 2021 à 10:47, Tim Starling <tstarl...@wikimedia.org> a écrit :
> On 25/11/21 7:55 pm, Nicolas Grekas wrote: > > > I voted yes because I want to see this happen but I raised a point in > https://externals.io/message/116141#116259 and didn't get an answer: > > Despite their name, I never used natcase functions for natural language >> processing. I use them eg to sort lists of files in a directory, to >> account >> for numbers mainly. But that's not what I would call natural language >> processing. I'm not aware of anyone using them for that actually. I'm >> wondering if it's a good idea to postpone migrating them to an >> hypothetical >> future as to me, the whole reasoning of the RFC applies to them. >> > > I wish the strnatcasecmp() and natcasesort() function, but also the > SORT_NATURAL flag were also covered by this RFC. > Is that possible? Would it make sense? > > > I'm not going to migrate those functions at this time. It's just a project > scope decision. > Why? The RFC says: > because they also use isdigit() and isspace(), Does that mean "too much work needed"? I would totally understand that of course but I hope someone could do these last miles. > and because they are intended for natural language processing I definitely do not agree with this argument and it should be removed from the RFC to me as it might add confusion in the future. Nicolas
