Hello Internals,
As [Danack](https://github.com/Danack) has mentioned in the [PR
comments](https://github.com/php/php-src/pull/4073#issuecomment-487186654), i
want to discuss this here before writing an RFC.
What do you think about adding the `arraykey` type to PHP.
see :
- https://docs.hhvm.c
On Fri, Apr 26, 2019 at 6:10 AM Rowan Collins wrote:
> On Thu, Apr 25, 2019 at 6:07 PM Theodore Brown wrote:
>
> > Is there any chance the Number Format Separator RFC [1] could be revived
> > for PHP 7.4? I looked at the discussion from a few years ago and it's
> > not clear why many people orig
On Fri, Apr 26, 2019 at 3:51 PM Pedro Magalhães wrote:
> On Thu, Apr 25, 2019 at 8:15 AM Nikita Popov wrote:
>
>> Any website using short_open_tags without explicitly
>> enabling it (relying on the default) will leak source code unless proper
>> precautions are taken before switching to PHP 7.4.
On Thu, Apr 25, 2019 at 8:15 AM Nikita Popov wrote:
> Any website using short_open_tags without explicitly
> enabling it (relying on the default) will leak source code unless proper
> precautions are taken before switching to PHP 7.4.
>
> In PHP 7.4:
> * The default value of short_open_tag remai
On Fri, Apr 26, 2019 at 3:10 PM Benjamin Morel
wrote:
> > Yes, PHP 8 for BCs and PHP 7.4 for warnings that's what I was trying to
> said
>
> FWIW, I don't think anyone will complain about adding a warning to
> something that's obviously a bug when it fails.
> I'd say go ahead a write an RFC. If y
> Yes, PHP 8 for BCs and PHP 7.4 for warnings that's what I was trying to
said
FWIW, I don't think anyone will complain about adding a warning to
something that's obviously a bug when it fails.
I'd say go ahead a write an RFC. If you want to have more chances for it to
pass though, I would not cha
> Another option might be to introduce an object-oriented layer on top of
> libbcmath
I think it should be a separate discussion for this. Create new
discussion so we can talk there.
>> Throwing an exception would be rather uncommon for functions, and would
>> definitely have to wait for PHP 8 f
> Throwing an exception would be rather uncommon for functions, and would
> definitely have to wait for PHP 8 for BC reasons.
Sure. This is actually a discussion I'd like to start for all PHP functions
in PHP 8.
>Another option might
> be to introduce an object-oriented layer on top of libbcmath.
On 26/04/2019 12:10, Rowan Collins wrote:
This is a poor example, because phone numbers shouldn't be stored as
integers; there's nothing you can do with them mathematically, and outside
of North America it's extremely common for them to have significant leading
zeroes.
Along with flagging the c
> > On Thu, Apr 25, 2019 at 6:07 PM Theodore Brown
> > wrote:
> >
> >> Is there any chance the Number Format Separator RFC [1] could be revived
> >> for PHP 7.4? I looked at the discussion from a few years ago and it's
> not
> >> clear why many people originally voted against it.
>
Hi,
I'm not
On 26.04.2019 at 09:45, Benjamin Morel wrote:
>> I don't really understand it, I must be strict, converting to zero
>> will lead to wrong calculations.
>
> That's what I said :) Fully agree here, any non-numeric string should throw
> an exception.
>
> In summary, I would check that the string matc
Hi Vladyslav,
> I don't really understand it, I must be strict, converting to zero
> will lead to wrong calculations.
That's what I said :) Fully agree here, any non-numeric string should throw
an exception.
In summary, I would check that the string matches `
/^[\+\-]?[0-9]+(\.[0-9]+)?$/`or else
12 matches
Mail list logo
