What about going forward with the trailing whitespace RFC right now, but
ask to vote between 3 options?
- NO - leave as it is
- YES - allow trailing whitespace
- YES - disallow leading whitespace
And then proceeding with the string to number comparison RFC?
Ben
On Thu, 4 Apr 2019 at 01:15,
>
> Quite honestly knowing that a function “throws” but not *what* it throws,
> is useless.
> Now if it were a proposal to add *runtime checked* `throws FooException,
> BarTypeError` or similar, I could get behind.
Same here.
On Thu, 4 Apr 2019 at 02:48, Stephen Reay wrote:
>
>
> > On 4 Apr
The PHP development team announces the immediate availability of PHP
7.3.4. This is a security release which also contains several bug fixes.
All PHP 7.3 users are encouraged to upgrade to this version.
For source downloads of PHP 7.3.4 please visit our downloads page.
Windows binaries can be
On 06/03/2019 08:58, Nikita Popov wrote:
1. What is more important to me here than strictness is consistency. Either
both " 123" and "123 " are numeric, or neither are. Making "123"
numeric is a change we can easily do, because it makes the numeric string
definition more permissive and
Hi internals,
Thanks for the people who joined the discussion of my [RFC: Spread Operator in
Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The
biggest change is I have dropped the support for string keys in v0.2 as
suggested by Côme, to make the behavior of spread
> Quite honestly knowing that a function “throws” but not
> *what* it throws, is useless.
>
> Now if it were a proposal to add *runtime checked*
> `throws FooException, BarTypeError` or similar, I could get behind.
>
Agreed. I use noexcept in C++ *because* it adds value. If this proposal
were
Hi,
The PHP development team announces the immediate availability of PHP
7.2.17. This is a security release which also contains several minor bug
fixes.
All PHP 7.2 users are encouraged to upgrade to this version.
For source downloads of PHP 7.2.17 please visit our downloads page.
Windows
Hello,
what about exposing a strict keyword option or a php ini option?
- NO - leave as it isdefault
- YES - allow trailing whitespace punks
- YES - disallow leading whitespace sane people
On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel
wrote:
> What about
Hi CHU Zhaowei,
Where can I find first RFC version? Revisited RFCs AFAIK should be served
under different name.
Personally I liked key preserve behavior. Without it use of spread operator
I array expression would have minor use. But this is my personal feeling
about only.
I think I'm missing
On Thu, 4 Apr 2019 at 17:14, Derick Rethans wrote:
> Could you add to the RFC what the exact pain point is that this is
> trying to address? It looks a little like this is just adding syntax for
> the sake of it.
>
Not everything is about pain, some things are just about gain. ;)
The link
Hey,
We have banned this "spam2" user from internals, but he's still being an
ass on the bug system. Should I have a look at whether we can get him
out of there as well?
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation:
>
> what about exposing a strict keyword option or a php ini option?
There is a trend right now towards avoiding the language to be dependent on
php.ini options. I'm on board with this, and would personally strongly
discourage introducing such an option, and enforce one of these options for
Hello,
Yes and No php has an existing echo-system of extensions which could not
work
without this ini model; therefor it's fashion trend which is in my opinion
unrealistic or you
are ready to break existing infrastructures.
Enforcing the right behavior (third one) will break existing code big
Hi!
On Thu, 4 Apr 2019, CHU Zhaowei wrote:
> Thanks for the people who joined the discussion of my [RFC: Spread
> Operator in Array
> Expression](https://wiki.php.net/rfc/spread_operator_for_array). The
> biggest change is I have dropped the support for string keys in v0.2
> as suggested by
> On 4 Apr 2019, at 21:14, CHU Zhaowei wrote:
>
> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread Operator
> in Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The
> biggest change is I have dropped the support for string keys in
The PHP development team announces the immediate availability of PHP
7.1.28. This is a security release.
All PHP 7.1 users are encouraged to upgrade to this version.
For source downloads of PHP 7.1.28 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The
On Thu, Apr 4, 2019 at 9:58 AM Michał Brzuchalski
wrote:
>
> Hi CHU Zhaowei,
>
> Where can I find first RFC version? Revisited RFCs AFAIK should be served
> under different name.
Look at its history. Using the same URL is fine, as long as author(s) agree.
> Personally I liked key preserve
> On 5 Apr 2019, at 08:54, Larry Garfield wrote:
>
> On Wed, Mar 13, 2019, at 10:22 PM, Larry Garfield wrote:
>> On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote:
>>> On 13/03/2019 21:10, Dik Takken wrote:
>
>> If I can summarize the responses so far, they seem to fall into one of
>>
On Wed, Mar 13, 2019, at 10:22 PM, Larry Garfield wrote:
> On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote:
> > On 13/03/2019 21:10, Dik Takken wrote:
> If I can summarize the responses so far, they seem to fall into one of
> two categories:
>
> 1) Love the idea, but wouldn't
On 04/04/2019 16:17, Sara Golemon wrote:
I would say that any exception thrown in (1) should lead to an non-zero
exit since the program has violated an invariant assumption.
The problem with enforcing an exception contract at runtime is surely
how to avoid the cure being worse than the
20 matches
Mail list logo
