As mentioned earlier:
In hack (hhvm), operators like +=, *= etc do allow the left side to be
undefined.
(However, ++ and -- do not allow the left side to be undefined.)
I wonder if this is intended, or by accident.
On 20 January 2018 at 06:47, Andreas Hennings wrote:
> On 20 January 2018 at 04:2
On 20 January 2018 at 04:29, Aidan Woods wrote:
> On 20 January 2018 at 01:25, Andreas Hennings wrote:
>>
>> On 19 January 2018 at 16:12, Sara Golemon wrote:
>> > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker
>> > wrote:
>> >> On 18.01.2018 at 23:58, Stanislav Malyshev wrote:
>> >>
>> >>
On 20 January 2018 at 01:25, Andreas Hennings wrote:
> On 19 January 2018 at 16:12, Sara Golemon wrote:
> > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker
> wrote:
> >> On 18.01.2018 at 23:58, Stanislav Malyshev wrote:
> >>
> I propose even more such operators:
> null coalesce a
On 19 January 2018 at 16:12, Sara Golemon wrote:
> On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker
> wrote:
>> On 18.01.2018 at 23:58, Stanislav Malyshev wrote:
>>
I propose even more such operators:
null coalesce addition assignment ??+= (for strings and numbers)
null coales
On Fri, Jan 19, 2018 at 4:04 PM, Sam Ding wrote:
> The test case ext/standard/tests/general_functions/bug72300.phpt is failed
> on s390x.
> The function "ignore_user_abort" returns "256" on s390x, and "1" on x86_64
> after "ignore_user_abort" is set to true;
> The root reason is because of Big_End
Hi again,
On Fri, Jan 19, 2018 at 9:30 PM, Niklas Keller wrote:
>
> I think we only have to bump the minimum version once 7.4 is out, because
> only 7.4 will change the default. You only get a deprecation notice now,
> which is totally fine.
>
I disagree that it's totally fine. I mean, it's tech
Hi all,
The test case ext/standard/tests/general_functions/bug72300.phpt is failed
on s390x.
The function "ignore_user_abort" returns "256" on s390x, and "1" on x86_64
after "ignore_user_abort" is set to true;
The root reason is because of Big_Endian on s390x.
Here is the C code: ext/standard
2018-01-19 20:09 GMT+01:00 Andrey Andreev :
> On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon wrote:
> > (Seriously though, who's on php 7.2, but hasn't updated ICU for that
> > long?)
>
> Probably nobody yet. The issue was uncovered in code that assumed the
> constant was available on 5.4+, as not
On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon wrote:
> (Seriously though, who's on php 7.2, but hasn't updated ICU for that
> long?)
Probably nobody yet. The issue was uncovered in code that assumed the
constant was available on 5.4+, as noted in the manual, but it turned
out there's people on 5.
On Fri, Jan 19, 2018 at 1:11 PM, Andrey Andreev wrote:
> My immediate thought is to simply bump the ICU version requirement,
> but I have no idea what kind of an impact that would have.
>
According to that page, 46 is seven years old. I for one am 100% okay
with making that the minimum, though no
Hello,
It seems that an important detail was missed in the RFC to deprecate
INTL_IDNA_VARIANT_2003 in PHP 7.2.0 (and later remove it). The only
other option available - INTL_IDNA_VARIANT_UTS46 - may not be
available at all, as PHP has ICU 4.0 as its minimum requirement, but
support for UTS#46 was
On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker wrote:
> On 18.01.2018 at 23:58, Stanislav Malyshev wrote:
>
>>> I propose even more such operators:
>>> null coalesce addition assignment ??+= (for strings and numbers)
>>> null coalesce subtraction assignment ??-=
>>> null coalesce increment ?
12 matches
Mail list logo
