Results for project PHP master, build date 2017-08-09 19:23:09-07:00
commit: c8efaea
previous commit:4804d64
revision date: 2017-08-09 11:30:13+08:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Fri, Aug 11, 2017 at 12:01 AM, Devnuhl Unnamed wrote:
> Would isset($suffix) not suffice here?
You mean like so?
list($prefix, $suffix) = explode(':', 'string_without_suffix');
if (!isset($suffix)) {
..
}
The isset() is too late here, because the list() will already cause an error.
> Oth
Would isset($suffix) not suffice here? There are several things I've
thought of that would be other alternatives to changing this language
construct, but as I don't have my laptop with me, some of the testing to
confirm behavior will have to wait.
Other concerns fall around list() already being a
On Thu, Aug 10, 2017 at 5:21 PM, Andreas Hennings wrote:
> I found this RFC, describing a feature I wanted for a long time:
> https://wiki.php.net/rfc/list_default_value
> https://marc.info/?l=php-internals&m=144707619509724
>
> I regularly want this kind of feature when unpacking a string with ex
I don't have a strong opinion about the nested list() construct which
is also part of the RFC.
I never had a situation where I wanted this.
On Thu, Aug 10, 2017 at 11:21 PM, Andreas Hennings wrote:
> Hello list,
>
> I found this RFC, describing a feature I wanted for a long time:
> https://wiki.p
Hello list,
I found this RFC, describing a feature I wanted for a long time:
https://wiki.php.net/rfc/list_default_value
https://marc.info/?l=php-internals&m=144707619509724
(I don't know how to correctly reply to old emails that are not in my
inbox, sorry for that. I don't like mailing lists.)
On Sun, Aug 6, 2017 at 12:49 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
> > bug, with the justification that unserialize() should not be fed
> untrusted
> > input. While we do document that unserialize() shouldn't be used on
>
