On 24 October 2014 07:03, Joe Watkins <pthre...@pthreads.org> wrote: > On Thu, 2014-10-23 at 12:54 -0700, Stas Malyshev wrote: > > Hi! > > > > > P.S. u() is a bad name, will break lots of code, i.e. > > > > Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's > safe. > > > > /me cringes ... > > I wonder how much of a problem it really is, usually when we say some > function name is a problem is because of hundreds and hundreds of > results on github. > > If it's a huge problem then we should rename it, if we have to dig > around for a single project that's incompatible, or even a handful, then > it's not really a problem. > > Cheers > Joe
I can see this being something relatively common. While I personally would never do it, there are a few reasons I can think of that people *might* do it: - Wrapper for creating <u> HTML output - urlencode() shortcut - (obviously) various unicode-related things Searching on codesearch [1] revealed (amongst a few other hits on the first page) another interesting use of it in the hhvm test suite [2]. It's difficult to search for this because all the available public search engines that I know of do fuzzy matching. Sorry. This sucks, because every other option we have for this is sucks. On the bright side, anything chosen could always be aliased at the top of the file: use function __u as u; This also sucks, but it sucks a little bit less because the collisions are avoided - or at least, avoided in such a way that the onus is on the user - and one can still have the sane name. First-class support at the syntax level (presumably $foo = u"unicode string" since we already have $foo = b"binary string") would IMO be better and (hopefully?) a long-term goal, but I am aware that it is - and probably should be - outside the scope of the current proposal. [1] https://searchcode.com/?q=function+u+lang%3Aphp [2] https://github.com/facebook/hhvm/blob/master/hphp/test/slow/ext_icu/uspoof.php#L13
