Sorry for top posting, but should we be discussing these at this point? If these are targeting 7.4, I think we probably want to focus on the ones slated to 7.3 at this point.
Perhaps we can add some further blurb (maybe in a box) that despite the RFC acronym, at this point this is just a list of items to discuss at a future time..? Zeev > -----Original Message----- > From: Stanislav Malyshev [mailto:smalys...@gmail.com] > Sent: Wednesday, June 27, 2018 3:39 AM > To: Kalle Sommer Nielsen <ka...@php.net>; Nikita Popov > <nikita....@gmail.com> > Cc: Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3 > > Hi! > > > - The (real) type-cast and its function, is_real(). There doesn't > > seem to be any support for reals in settype() anyway (side note: in > > the implementation of settype() it claims "double" is deprecated) > > - Function variants that already exists as constants, php_sapi_name() > >> PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc > > Weighting bc preak potential vs. improvement benefit, I am not sure it's > worth it > for both. Maybe for "real" it's ok as I haven't really seen anybody using it > in > ages, looks like most Fortran programmers either retired or aren't using PHP > :) > > > - enable_dl ini directive, as dl() is only operational for CLI and > > Embed anyway > > Makes sense. > > > - The 'b' constant string prefix, its not used and was meant as to > > make code ready for PHP6, should the time come where we want to add a > > feature that uses this, we can always re-add it > > Yeah this one we probably just have to remove, it doesn't do anything now. > > > Other things thats been suggested by others in the past: > > > > - Second parameter of spl_autoload() and its associated function > > spl_autoload_extensions() > > Why? > > > - hebrevc() -- same as hebrev() + nl2br(), perhaps even deprecate > > hebrev() too (see next one) > > Probably less useful now that browsers finally can render bidi texts > properly, but > may be still useable for workloads where bidi rendering is not available. And > I > see no problem with function doing something that is achievable by other > functions. > > > - convert_cyr_string() -- Point to mb_convert_encoding() / iconv > > Maybe just make it a pseudo-alias for iconv? > > > - The alternative string interpolation syntaxes (${varName}, > > ${varName['offset']}, ${expr}) and make them more consistent > > ({$varName}, {$varName['offset']}, {${expr}}) > > I'm not sure how one is "more consistent" than the other. > > > - The historial parameter handling that works both ways for > > implode(), should be unified to match that of explode() > > I'd advise against messing with such widely used function as implode()... > > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
