In D25249#8543, @speck wrote:

The reason that @ is used instead of try/catch -- the comment on the function is saying if you have a string in e.g. Latin-1 and $to_encoding is set to something different-yet-valid such as Korean (e.g. ISO-2022-KR) -- then the encoding conversion will silently fail, not throwing an exception, but still populating the result with incorrect garbage.

@valerio.bozzolan, do you want to commandeer this revision and add the cast yourself?

This patch suppresses the deprecation errors at each site, but there might be a simpler workaround in the same spirit: change the error_reporting calls (of which there are only a handful) to exclude E_DEPRECATED. That would risk masking any other deprecations (probably fine in production, but not in development), whereas this patch risks hiding any non-deprecation errors at these locations.

Although there's merit to the "zero, one, infinity" rule, it might not be the best option here. If something goes wrong and $err happens to always be falsy, this will end up in an infinite loop instead of giving a clear error message. There is probably a reasonable finite value (that's greater than 4) which can be chosen as the limit to the number of attempts.

There are some projects listed on the Phabricator Community Resources page. Would all of those be eligible for hosting here, or would there be some criteria to limit the number of external projects?

But why would we need to explicitly keep them? They already exist upstream...

My suspicion, though I hadn't thought through it much, is that it might be useful during migration periods where someone has the repository checked out and there's are clear linear branches of the phabricator development vs. phorge development.