You can achieve the same results using preg_replace:

preg_replace('/./e',"sprintf('%%%02X',ord('\\0'))",$foo);

The resulting string can be parsed by any RFC compliant query string decoder.

That's true.  You could also do the following and dispense with the built in functions entirely, but it's not very convenient (and perhaps less efficient?).

preg_replace( array( '/[^\w. -]/e', '/ /' ), array( "sprintf( '%%%02X', ord( '\\0' ) ) ", '+' ), $foo_original );

preg_replace( '/[^\w.-]/e', "sprintf( '%%%02X', ord( '\\0' ) )", $foo_original );

That's some pretty complicated code, that you have to go through the hassle of carrying around with you everywhere you need it, to perform a pretty simple action.  I don't understand why you just automatically decided to condemn this to "Wont fix".  It seems like it would be pretty simple to implement, and the change I suggested wouldn't interfere with anything.  The usefulness / necessity is self-evident and demonstrated by the existence of the current built in functions.

What's neither useful nor self-evident is what the value of encoding alphanumerics and other non-special characters is.

You're absolutely right when you say that it's a simple matter to add this function and that it won't break BC.  The reason this is marked "Won't Fix", however, is because there are literally hundreds of such functions which, while taken individually are trivial and harmless, while taken together add up to a great deal of bloat.

Have you considered creating a PEAR class?  Possibly one which includes other URL related functionality as well.  One of the reasons the PEAR and PECL repositories were created (the chief reason in fact) was to allow functions such as what you describe to be 'standard' without adding to what is (let's be honest) an already overloaded scripting engine.

Thanks for explaining the reasoning behind your decision.

I applaud your efforts to curb bloat in PHP.  I am in complete agreement with you on that subject and I can see that you're well informed about the issues involved.

'Such functions add up to bloat.'  When you say "such functions" do you mean urlencode() and rawurlencode()?  If you please, I didn't suggest creating a new function, I simply suggested adding an optional argument to those two existing functions.

That really seems like overkill, to create a PEAR class to do one simple thing that is only a very slight variation of what a built in function already does, which the function could, as you yourself said, very easily, compatibly be made to do.

Several times you've mentioned the negative affect adding many trivial functions to PHP can have, and I can see your point.  But, so there is no misunderstanding, I repeat that I did not suggest adding a new function, merely the enhancement of two existing functions by the addition of an optional argument.

I'd be grateful if you could give this some consideration.

Thanks