The death of `#ifndef FAST_ZPP`?

Hi everyone, You may recall that PHP 7.0 introduced a new API for processing arguments to internal functions, the "Fast Parameter Parsing API" or FAST_ZPP (https://wiki.php.net/rfc/fast_zpp), which is an alternative to the existing zend_parse_parameters function family. Since FAST_ZPP was implemented, many functions in built-in PHP extensions look like this: #ifndef FAST_ZPP if (zend_parse_parameters(ZEND_NUM_ARGS(), "S|S", &str, &what) == FAILURE) { return; } #else ZEND_PARSE_PARAMETERS_START(1, 2) Z_PARAM_STR(str) Z_PARAM_OPTIONAL Z_PARAM_STR(what) ZEND_PARSE_PARAMETERS_END(); #endif That is, they have /two/ sets of parameter processing code: one using the old API, and one using the new API, with conditional compilation. This is necessary because it is still possible to turn off FAST_ZPP by changing the value of the macro. However, should that be the case? The FAST_ZPP RFC was approved and PHP 7.0 was released containing it enabled by default, so it's no longer just an experimental performance enhancement. Furthermore, I have no reason to believe that the option to turn off FAST_ZPP is actually used in practice, though feel free to prove me wrong! Requiring all usages of FAST_ZPP to be accompanied by a zend_parse_parameters() fallback creates code bloat. It also creates hidden, potentially build-breaking bugs, because the code is rarely built with FAST_ZPP disabled. It's like the old TSRMLS_CC situation. Furthermore, for those who would prefer the FAST_ZPP API, it is inconvenient that they cannot use it exclusively and must also use zend_parse_parameters(), doubling the effort. So, I would like to ask: would there be any objections to going through and removing all unnecessary zend_parse_parameters fallbacks, and making it impossible to disable FAST_ZPP? This would make the two APIs equally valid. Thanks! -- Andrea Faulds https://ajf.me/