Hi!
Technically, yes, it is possible. But is it desirable? It would require breaking the abstraction and looking at the actual values of the flags, choosing one of the unused bits (possibly a high one) and hope it'll never be used in future. Plus, in the current patch, the value of the variant completely changes the return value (from string to array) so if it's more appropriate to single it out.
I think yes, it's better to have one options set than "options" and "another options which aren't first options but different options". I don't think there's breaking of abstraction if we use more options that ICU has, and probability of ICU using all 32 bits seems quite low for me now.
I don't think we should return array there - it makes using the function much more awkward since you need to check options before you know what it returns. I think it's better to have normal return always a string, abnormal can be handled by a special value if the user cares.
I don't really care or way or the other about pass-by-ref vs mixed return, but I don't think your position on that issue is clear here, as you only affirm that trying to force generic intl error reporting is not an option (which I've also argued). If there are no objections, I'll advance with mixed return, as Pierre has announced.
Actually, that's what I was objecting to. I think mixed return (i.e. function returning array or string depending on option) is not the best option. I think for most use cases people would just use the string and if the return is false they can either say "bad domain name" and be done with it, or parse the error codes and create special handling for each of them if they like. But I don't think there's a need to add so much complication by making the same function return two types.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
