Hi! > IMO, we should go the other way. Deprecate excess args in userspace > functions (making them an error in 8.0). We've had formal variadics > in userspace for a long time (5.5 IIRC), this is a solvable problem.
I think it's premature. We do have variadics, since 5.6 (https://github.com/php/php-src/blob/PHP-5.6/UPGRADING) but that's not "a long time" - not for PHP code and for the speeds people upgrade. There are still major code bases running on 5.x. There's still tons of code out there which does variadics the old-fashioned way, and I don't see any reason to break it - we do not gain anything from it. We should not force people to use variadics just for variadics' sake where their old code is already working. My position remains - there should not be BC breaks that don't gain people some benefit in some way. For example, there should not be BC breaks just to promote a new feature, even if it's way better than the old way - as long as the old way still works fine and does not cause trouble. This seems to be such case - non-variadic calls still work, and as far as I see, there's no improvement that allowing extra arguments breaks or makes harder. I think I'd rather allow extra args everywhere than ban them in user functions. But just having a warning in zero-arg internals is fine too - there we *can* know these weren't intended to be variadics, so we *can* know it's probably a mistake, unlike with user functions where in the generic case we don't know that. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
