Hi! > Good evening again, > > Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow > > Thoughts appreciated, as is help with the patch, though I can probably manage > on my own.
It would be nice to describe why this change is good. So far the motivation is "it is unintuitive" which is a fancy way of saying "I don't like it". Could you list which use cases this functionality improves, which real-life bugs it could fix, etc.? If this is necessary for your BigInt RFC which would not work without it for some reason (I have no idea if it is the case, but if it is) then please state so explicitly and describe why. That may also help to find alternatives in case somebody else sees any other solution that you may have missed. If there are some other arguments for it, please add them to the RFC. Right now it looks kind of thin. I personally don't have any reason to assume what you are proposing is better that what we have now, and BC break is a cost that always must be offset by something that is worth more. Especially a BC break in a form of "it worked before but now it fails" - this can break code in so many hard to catch ways, where you didn't actually care at the least if the function truncates the arg (common situation in proxy/glue libraries, etc. - they'd be completely fine with garbage in - garbage out) but need special code to handle situations where the function fails to run altogether. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
