Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102439
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.208.52 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c_+GZNrV1SC9q=Y3C=L3LMnoXX7J3zK6=kS9-sMXHZZow@mail.gmail.com>
References: <CAF+90c_+GZNrV1SC9q=Y3C=L3LMnoXX7J3zK6=kS9-sMXHZZow@mail.gmail.com>
Date: Mon, 25 Jun 2018 14:32:07 -0500
Message-ID: <CAESVnVrJo8BH=gMf07qq9MsgT6ziqWJO6JPgxVgVuStr+-5cpw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
From: pollita@php.net (Sara Golemon)

On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <nikita.ppv@gmail.com> wrote=
:
> https://wiki.php.net/rfc/deprecations_php_7_3
>
> Undocumented mbstring function aliases
>
Yeah, if they're just dumb aliases, then it's a slight gain to narrow
the symbol table by removing duplicates.  A modest composer package
(nay, include file) would be sufficient to provide a bridge for
existing projects which use the removed aliases once they're gone.
This deprecation isn't *needed*, but it's also fairly low impact. =F0=9F=A4=
=B7

> String search functions with integer needle
>
Agree with stas, the wtf quotient on this one is high.  Mitigating
this is the availability of strict types, but even still I think
deprecating the behavior altogether is a wise move.  Callers can
easily insert a call to chr() (or IntlChar::chr() ) to maintain the
old behavior in a version agnostic way. =F0=9F=98=95

> fgetss() function and string.strip_tags filter
>
"...these functions seem to be of very little utility..." [citation needed]
Anecdotally I struggle to imagine the use-case, but my imagination
isn't what it once was.  There's not a trivial workaround for someone
who's dealing with a large/streaming data source from which they want
to strip tags.  Deprecating this should come at a higher standard of:
proving that it is used, providing a userspace replacement, or both.
=F0=9F=98=A4

> Defining a free-standing assert() function
>
Eww, yeah. I can see that problem.  I'm not a huge fan of banning all
namespaced assert() function declarations, but it's certainly the most
direct "solution" to the problem.  A very quick scan of github only
shows one effected usage in a repo with no followers/stars apart from
the owner.  Given the lack of whole-program analysis, it's either ban
the declarations, or abandon elision.  Frankly, the number of people
taking advantage of the free dev-only check is probably way higher
than the number trying to define a function called 'assert' so.... =F0=9F=
=98=AC

-Sara