RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[CHU Zhaowei]

Thanks Rowan. IMO it's very natural to try to apply operators to similar 
scenario, array construction in this case, and I'm completing the missing piece 
of jigsaw puzzle.

Here is a MDN document for spread operator in JS: 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals
 and hope you find more useful examples.

TL;DR: this RFC is not making something impossible to become possible, it's 
making something not so easy to become easy and efficient.

-Original Message-
From: Rowan Collins  
Sent: Friday, April 5, 2019 12:40 AM
To: Derick Rethans 
Cc: CHU Zhaowei ; PHP internals 
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

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 Levi shared about Dart included some interesting examples of where 
spreads are useful, some of which you can probably imagine happening in
PHP:
https://medium.com/dartlang/making-dart-a-better-language-for-ui-f1ccaf9f546c

It also takes us a step closer to having a short-hand for iterator_to_array, in 
the shape of [...$iterator]. On its own, that's still pretty ugly, but it's not 
hard to come up with cases where it would be a lot nicer, like concatenating 
two iterators:

// Before
array_merge(iterator_to_array($iter1), iterator_to_array($iter2))

// Or to generalise to all iterables
array_merge( is_array($iter1) ? $iter1 : iterator_to_array($iter1),
is_array($iter2) ? $iter2 : iterator_to_array($iter2) )

// After (handles both cases)
[ ...$iter1, ...$iter2 ]

Granted, I can't point to a real-life example of that, but it shows that this 
isn't just new syntax for something that's already easy.

Regards,
--
Rowan Collins
[IMSoP]




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[CHU Zhaowei]

A recoverable error will be thrown once a string key is encountered. Thanks for 
raising this question, and I've updated the RFC accordingly.

-Original Message-
From: Stephen Reay  
Sent: Friday, April 5, 2019 12:40 AM
To: CHU Zhaowei 
Cc: PHP internals 
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2



> 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 v0.2 as 
> suggested by Côme, to make the behavior of spread operator consistent. I have 
> also added Q&A to explain the questions I received.
> 
> Thanks & best regards,
> CHU Zhaowei
> 
> 
> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, 
> visit: http://www.php.net/unsub.php
> 

Can you clarify what “not supported” means in reference to string keys? What 
will happen if an array with string keys is used? Does it error/warn, and/or 
are the keys ignored or skipped? 



--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
http://www.php.net/unsub.php
 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Draft: Comprehensions

[Stephen Reay]

> 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 
>> two categories:
>> 
>> 1) Love the idea, but wouldn't short-closures be close enough?
>> 
>> 2) Love the idea, but hate the particular syntax proposed.
>> 
>> On the plus side, it seems almost everyone is on board in concept, so 
>> yay.  That of course just leaves the syntax bikeshedding, which is 
>> always the fun part.
> 
> Bumping this thread again.
> 
> Thinking on it further, I see two possible syntactic approaches, given that 
> short lambdas as currently written would not give us a viable comprehension 
> syntax.
> 
> 1) [foreach ($list as $x => $y) if (condition) yield expression]
> 
> That is, essentially the same syntax as the list would be if wrapped in a 
> function, but with a more compact way of writing it.  The above would be 
> effectively identical to:
> 
> $gen = function () {
> foreach ($list as $x => $y)
>   if ($condition)
> yield expression;
> }();
> 
> 
> (But with auto-capture.)  I am personally not at all a fan of the extra 
> verbosity (foreach, parens, etc.) but it seems most respondents in the thread 
> want it for familiarity.
> 
> Advantages:
> 
> * Very compact.
> * Works for both arrays and traversables
> * Would play very nicely with the proposed spread operator for iterables 
> (https://wiki.php.net/rfc/spread_operator_for_array).
> 
> Disadvantages:
> 
> * New syntax
> * If you need to do multiple filter or map operations it gets potentially 
> ugly and unwieldy.
> * Not super extensible.
> * Doesn't have a natural way to enforce the types produced.  (Although one 
> could add it easily.)
> 
> This approach has the advantage of being compact and working for both arrays 
> and traversables, but is new syntax.
> 
> 2) Allow comprehensions to work only on traversable objects, which lets us 
> chain methods.  Specifically:
> 
> $new = $anyTraversable->filter(fn($x) => $x < 0);
> 
> Would return a new traversable that filters $anyTraversable, using a 
> callable.  It would effectively be identical to 
> 
> $new = new CallbackFilterIterator($anyTraversable, fn($x) => $x < 0);
> 
> Similarly:
> 
> $new = $anyTraversable->map(fn($x) => $x * 2);
> 
> Would produce a new traversable that lazily produces a function over the 
> items as they're returned.   Equivalent to:
> 
> $new = function () {
> foreach ($list as $x)
> yield expression;
> }();
> 
> And both would also need to support a key/value as well, probably if the 
> callable takes 2 parameters then it's $key, $value, if just one parameter 
> then it's just $value.
> 
> This approach has a few advantages:
> 
> * It piggy-backs on existing traversable behavior; essentially, rather than 
> short-syntax for generators it's short syntax for wrapping a bunch of 
> iterator objects around each other.
> * More elaborate cases (multiple filters, multiple maps) become somewhat 
> nicer; you can easily call filter() or map() multiple times and it's still 
> entirely obvious what's going on.
> * Has a natural (if verbose) way to enforce types: filter(fn($x) => $x 
> instanceof Foo || throw new \TypeError);
> * Actually, since short-lambdas already would support return type 
> declaration, there's another alternative: filter(fn($x) : Foo => $x);  
> (Although you'd probably just fit that into a filter function you're using 
> for something else.)
> * next() is already a useful method that works for the an() case discussed in 
> the RFC, and it flows very naturally.  I don't see a nice equivalent of 
> all(), however.
> 
> But also some disadvantages:
> 
> * It only works for traversable objects, not arrays.  (Workaround: new 
> ArrayObject($arr).)
> * It is more verbose than the other syntax option.
> * Adding special-meaning methods to Traversable objects is weird, and I don't 
> think we've done that anywhere before.  I have no idea if there are engine 
> implications.
> * The short lambda RFC becomes effectively a prerequisite, as it's way too 
> verbose to do with an anon function as we have now.
> * My gut feeling is it would be slower as it would likely mean more function 
> calls internally, but I've zero data to back that up.
> 
> And before someone else mentions it, it also poses some interesting possible 
> extensions that are not all that relevant to the current target, but would 
> fit naturally:
> 
> * a ->limit(0, 3) method, that is functionally equivalent to \LimitIterator.
> * Potentially RegexIterator() could also become a regex() method, that's a 
> special case of filter()?
> * Languages like Rust have a method to "run out" the comprehension ( 
> .collect() in the case of Rust).  We could easily do the same to produce a 
> resultant array, similar to the spread operator.  (That said, that should in 
> no way detract f

Re: [PHP-DEV] RFC Draft: Comprehensions

[Larry Garfield]

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 short-closures be close enough?
> 
> 2) Love the idea, but hate the particular syntax proposed.
> 
> On the plus side, it seems almost everyone is on board in concept, so 
> yay.  That of course just leaves the syntax bikeshedding, which is 
> always the fun part.

Bumping this thread again.

Thinking on it further, I see two possible syntactic approaches, given that 
short lambdas as currently written would not give us a viable comprehension 
syntax.

1) [foreach ($list as $x => $y) if (condition) yield expression]

That is, essentially the same syntax as the list would be if wrapped in a 
function, but with a more compact way of writing it.  The above would be 
effectively identical to:

$gen = function () {
  foreach ($list as $x => $y)
if ($condition)
  yield expression;
}();


(But with auto-capture.)  I am personally not at all a fan of the extra 
verbosity (foreach, parens, etc.) but it seems most respondents in the thread 
want it for familiarity.

Advantages:

* Very compact.
* Works for both arrays and traversables
* Would play very nicely with the proposed spread operator for iterables 
(https://wiki.php.net/rfc/spread_operator_for_array).

Disadvantages:

* New syntax
* If you need to do multiple filter or map operations it gets potentially ugly 
and unwieldy.
* Not super extensible.
* Doesn't have a natural way to enforce the types produced.  (Although one 
could add it easily.)

This approach has the advantage of being compact and working for both arrays 
and traversables, but is new syntax.

2) Allow comprehensions to work only on traversable objects, which lets us 
chain methods.  Specifically:

$new = $anyTraversable->filter(fn($x) => $x < 0);

Would return a new traversable that filters $anyTraversable, using a callable.  
It would effectively be identical to 

$new = new CallbackFilterIterator($anyTraversable, fn($x) => $x < 0);

Similarly:

$new = $anyTraversable->map(fn($x) => $x * 2);

Would produce a new traversable that lazily produces a function over the items 
as they're returned.   Equivalent to:

$new = function () {
  foreach ($list as $x)
  yield expression;
}();

And both would also need to support a key/value as well, probably if the 
callable takes 2 parameters then it's $key, $value, if just one parameter then 
it's just $value.

This approach has a few advantages:

* It piggy-backs on existing traversable behavior; essentially, rather than 
short-syntax for generators it's short syntax for wrapping a bunch of iterator 
objects around each other.
* More elaborate cases (multiple filters, multiple maps) become somewhat nicer; 
you can easily call filter() or map() multiple times and it's still entirely 
obvious what's going on.
* Has a natural (if verbose) way to enforce types: filter(fn($x) => $x 
instanceof Foo || throw new \TypeError);
* Actually, since short-lambdas already would support return type declaration, 
there's another alternative: filter(fn($x) : Foo => $x);  (Although you'd 
probably just fit that into a filter function you're using for something else.)
* next() is already a useful method that works for the an() case discussed in 
the RFC, and it flows very naturally.  I don't see a nice equivalent of all(), 
however.

But also some disadvantages:

* It only works for traversable objects, not arrays.  (Workaround: new 
ArrayObject($arr).)
* It is more verbose than the other syntax option.
* Adding special-meaning methods to Traversable objects is weird, and I don't 
think we've done that anywhere before.  I have no idea if there are engine 
implications.
* The short lambda RFC becomes effectively a prerequisite, as it's way too 
verbose to do with an anon function as we have now.
* My gut feeling is it would be slower as it would likely mean more function 
calls internally, but I've zero data to back that up.

And before someone else mentions it, it also poses some interesting possible 
extensions that are not all that relevant to the current target, but would fit 
naturally:

* a ->limit(0, 3) method, that is functionally equivalent to \LimitIterator.
* Potentially RegexIterator() could also become a regex() method, that's a 
special case of filter()?
* Languages like Rust have a method to "run out" the comprehension ( .collect() 
in the case of Rust).  We could easily do the same to produce a resultant 
array, similar to the spread operator.  (That said, that should in no way 
detract from the spread operator proposal, which I also like on its own merits.)
* Possibly other stuff that slowly turns iterables into "collection objects" 
(sort of).


Discussion:

For me, the inability to work with arrays is the big problem with the second 
approach.  I very very often 

Re: [PHP-DEV] Question about adding !function_identifier

[Rowan Collins]

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 disease.


The behaviour most consistent with the current language would be to 
throw an Error - this is what happens for other invariant violations 
like "null passed where an array was expected". But that doesn't really 
make any sense here: it would mean wrapping a meaningful exception in a 
generic UnexpectedExceptionError and then throwing it again, at code 
that's still not expecting it.


An immediate fatal error would be more practical, but I'm not sure what 
benefit it would bring. If the calling code has no way of catching the 
exception, it will eventually blow through the stack and become a fatal 
error anyway; but if it would eventually reach a catch block, what value 
is added by making it fatal immediately instead?


For instance:

function foo(): type nothrow {
   throw new SomethingException; // or, more likely, fail to catch one 
from a deeper call

}
function bar(): type throws ( SomethingException ) {
   throw new SomethingException;
}

try {
    foo();
    bar();
} catch ( SomethingException $e ) {
    log($e);
}

The program can clearly cope with a SomethingException and carry on; but 
because the author of foo() didn't fully test their code, it has no 
chance to and is killed outright instead.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7.1.28 Released

[Joe Watkins]

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 list of changes is recorded in the ChangeLog.

Release Announcement: http://php.net/releases/7_1_28.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.1.28

Many thanks to all the contributors and supporters!

Cheers
Joe

Follows is verification information:

php-7.1.28.tar.bz2
SHA256 hash:
739e8733fe1fc5e69e6226da6dba7a31bacfd2e3871ad2c97a792638f22c54c9
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlyjZBMACgkQ+boK2jHL
2J4Rggf/dEss6VLdfEpKGPLI3BvOmT+Xe1juuqi+l5GfDH4XNLjjpcY8GncGoJJL
UNxtYykeQXqwYR4eBX/KCZkVcKJv7wo+VdWRxWmqjKivUsaS0ITgavfBAd/NgGf0
40/uW/878KyQ6mKXLT5Dh/u5w1cx2OB69+HUiCH7xqezLm5HFSNFwjMl2Q07TAJ+
/nnR8QO/bSAghY9EK575CmB/Xs5h5iAFyAmd32lVGY9UC8BZtZjn3e+2Z6g68O6M
mghYsngTUggg5YDIH9nRc7ATyPsRDRjQ48OQPgo+J6BGHQLooGEsSu1cCBmFWCmy
R+9hrpkW+i9xA+OYDSkygmY6QBzaMQ==
=sXDP
-END PGP SIGNATURE-


php-7.1.28.tar.gz
SHA256 hash:
4df587338d4c5dfe27050c7ac72a6b7583ecaee9d3fbfc03427667a86e081999
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlyjZBMACgkQ+boK2jHL
2J566ggAoGPhR+UBxOKRavw2BKUU9BCZhABSb5GThaWPF3SwDkbuIcm/9RtIlzcq
7oeFeVM2OQFJ3JKBB7jurza8vIdyFi1obFPe56ipm9InNe+/wJj1mz1/dHFh325Y
OF9o5QAt76z9tMXHbIWRwIZ8dYPIp2R3y+JedPPE9YxNfD41Kf7+pjJi/w3t7Rbi
JVcB0G9t/O/5JT6KNiplgXJtYUYKKhJ1hamfvSJ4vlxp6hWajj+wenwOY4LvU8XI
JQv9tCiHElVolIJMfkCv/s7q/kPgtZVFe5Ftj+EKVZmCInN5kqI7nGIE+Bypf91P
YbZwN6z4SKfz/+4A/XTHuqtPwMo+Yw==
=il8x
-END PGP SIGNATURE-


php-7.1.28.tar.xz
SHA256 hash:
45131497ec0a947e3f9145c000e8fcc1f86b46518ee3f6810d80efa2d39521e2
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlyjZBMACgkQ+boK2jHL
2J6UfggAhjt1gieZYrMyF2FU+Nph17eImi+HmDY4Qn5BCujpB0Mfa/zI1/GPuWGc
6/62pVzCv/jjyaLgL+1aVaoB2Az8VmwGZbOcqpDy08EYztD2TiqRjAVdjiu4/ag9
ZVPcAgCveRdvnyjf5Z0Dns5q8IExHBYwX6BZieq3EfUXZCXjbEdVR0X+zPLl7yi9
A6pnmiTK56Qv4qjtz0aO8Fy4HY+eENXAuHRy6PuWfco+uC/0ClFA7jtWATADTTpq
J52PI/mJWyr3M2Uog5xyhDwM0S4I4KXwvbr4E0F5vABtFVzhqRBOmziSKW8itKgk
6kfJ4ORIHEuZkl/4WFfCOIgYHJ7Qlw==
=xERw
-END PGP SIGNATURE-

[PHP-DEV] Bug #77845 [Com]: Error in the comparaison (fwd)

[Derick Rethans]

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: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

-- Forwarded message --
Date: Thu, 04 Apr 2019 14:37:14 +
From: spam2 at rhsoft dot net 
To: php-b...@lists.php.net
X-Bogosity: No, tests=bogofilter, spamicity=0.00, version=1.2.4
Subject: Bug #77845 [Com]: Error in the comparaison

Edit report at https://bugs.php.net/bug.php?id=77845&edit=1

 ID: 77845
 Comment by: spam2 at rhsoft dot net
 Reported by:baklouti dot med at gmail dot com
 Summary:Error in the comparaison
 Status: Not a bug
 Type:   Bug
 Package:*Compile Issues
 Operating System:   ubuntu 18.04
 PHP Version:7.2.16
 Block user comment: N
 Private report: N

 New Comment:

hell post the code you are actually using instead f**g decriptions ike " am not 
using the two cases in the same time" - switch works, full stop, echo what $id 
contains really at that moment


Previous Comments:

[2019-04-04 14:34:18] baklouti dot med at gmail dot com

Yes, I try it with "case 0:" , and the same issue is happening.


[2019-04-04 11:21:37] ka...@php.net

Because `($id === 0)` is evaluated as an expression before, meaning that 
essentially the `case` statement now looks like `case 1:`. The correct way to 
do that which you are trying to would be to make your case statement simply 
look like `case 0:`.

Please refer to the documentation int the future:
https://www.php.net/manual/en/control-structures.switch.php


[2019-04-04 11:10:25] baklouti dot med at gmail dot com

Description:

I am testing the value of $id to do some processing. I retrieve the variable 
$id from an array ($test) and converted to integer, for the case that $id = 0 
when using "switch" it can't be detected and if I used the "if" it is working 
fine.
I tried with the "==" and the "===" and also not working with "switch".
I am not using the two cases in the same time, i tested the "if" and "switch"
separately.

  $id = (integer)$test['id'];

  if ($id === 0 ) {return 1;}

  switch ($id) {
 case ($id === 0):
return 2;
  



Expected result:

The expected result is the bloc inside the case ($id ===0) is processed. 

Actual result:
--
The actual result that it is passed for another case.






--
Edit this bug report at https://bugs.php.net/bug.php?id=77845&edit=1

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[Stephen Reay]

> 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 v0.2 as 
> suggested by Côme, to make the behavior of spread operator consistent. I have 
> also added Q&A to explain the questions I received.
> 
> Thanks & best regards,
> CHU Zhaowei 
> 
> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

Can you clarify what “not supported” means in reference to string keys? What 
will happen if an array with string keys is used? Does it error/warn, and/or 
are the keys ignored or skipped? 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[Rowan Collins]

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 Levi shared about Dart included some interesting examples of where
spreads are useful, some of which you can probably imagine happening in
PHP:
https://medium.com/dartlang/making-dart-a-better-language-for-ui-f1ccaf9f546c

It also takes us a step closer to having a short-hand for
iterator_to_array, in the shape of [...$iterator]. On its own, that's still
pretty ugly, but it's not hard to come up with cases where it would be a
lot nicer, like concatenating two iterators:

// Before
array_merge(iterator_to_array($iter1), iterator_to_array($iter2))

// Or to generalise to all iterables
array_merge( is_array($iter1) ? $iter1 : iterator_to_array($iter1),
is_array($iter2) ? $iter2 : iterator_to_array($iter2) )

// After (handles both cases)
[ ...$iter1, ...$iter2 ]

Granted, I can't point to a real-life example of that, but it shows that
this isn't just new syntax for something that's already easy.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[M. W. Moe]

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
time; hence at some point
you need to go with a transitional state; it does not say that one day
you'r not gonna retire it
and finally enforcing only one ((the right behavior (third one))).




On Thu, Apr 4, 2019 at 9:06 AM Benjamin Morel 
wrote:

> 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
> everyone instead.
>
> On Thu, 4 Apr 2019 at 17:05, M. W. Moe  wrote:
>
>> 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 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, Andrea Faulds  wrote:
>>>
>>> > Nikita Popov wrote:
>>> > > I'm always a fan of making things stricter, but think that in this
>>> > > particular case there are some additional considerations we should
>>> keep
>>> > in
>>> > > mind.
>>> > >
>>> > > 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 is thus mostly backwards compatible.
>>> Doing
>>> > > the reverse change is certainly not compatible and will be a much
>>> harder
>>> > > sell.
>>> > >
>>> > > 2. I believe that a large part of the motivation here is that by
>>> making
>>> > the
>>> > > numeric string definition slightly more lax (in a consistent
>>> manner), we
>>> > > can make *other* things more strict, because this essentially
>>> eliminates
>>> > > the only "somewhat reasonable" case of trailing characters. The RFC
>>> > already
>>> > > mentions two of them:
>>> > >
>>> > > a) We can hard reject "123foo" inputs to "int" arguments (and some
>>> other
>>> > > places). Currently this is allowed with a notice. I think if we
>>> resolve
>>> > the
>>> > > trailing whitespace question, then there cannot be any reasonable
>>> > > opposition to this change.
>>> > > b) My own RFC on number to string comparisons would benefit from
>>> this.
>>> > From
>>> > > initial testing it has surprisingly little impact, but one of the few
>>> > cases
>>> > > that turned up was this comparison with a string that had trailing
>>> > > whitespace.
>>> > >
>>> > > Personally I think both of those changes are a lot more valuable
>>> than a
>>> > > stricter numeric string definition without leading/trailing
>>> whitespace.
>>> >
>>> > I'm kinda unsure how to go forward because of these points. I would
>>> like
>>> > to see improved comparisons, and I would like to see the end of the
>>> > “non-well-formed” numeric string, and I think this whitespace RFC could
>>> > be helpful to both. But I can't see the future, I don't know whether
>>> > people will vote for removing leading or permitting traiing whitespace
>>> > and whether or not they will be influenced by or this will influence
>>> > opinion on the further improvements. ¯\_(ツ)_/¯
>>> >
>>> > I'm torn between:
>>> >
>>> > * Vote on allowing trailing whitespace
>>> > * Vote on disallowing leading whitespace
>>> > * Vote on which of those two approaches to go for
>>> > * Trying to bundle everything together and voting on it as a package.
>>> >
>>> > I'm probably thinking too strategically.
>>> >
>>> > Andrea
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[Derick Rethans]

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 Côme, to make the behavior of spread operator 
> consistent. I have also added Q&A to explain the questions I received.

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.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[Levi Morrison]

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 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 something in RFC. Usage in key preserved array
> expression is not covered and the RFC doesn't describe how it would behave.
>
> Thanks for the efforts on it

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[Benjamin Morel]

>
> 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
everyone instead.

On Thu, 4 Apr 2019 at 17:05, M. W. Moe  wrote:

> 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 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, Andrea Faulds  wrote:
>>
>> > Nikita Popov wrote:
>> > > I'm always a fan of making things stricter, but think that in this
>> > > particular case there are some additional considerations we should
>> keep
>> > in
>> > > mind.
>> > >
>> > > 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 is thus mostly backwards compatible.
>> Doing
>> > > the reverse change is certainly not compatible and will be a much
>> harder
>> > > sell.
>> > >
>> > > 2. I believe that a large part of the motivation here is that by
>> making
>> > the
>> > > numeric string definition slightly more lax (in a consistent manner),
>> we
>> > > can make *other* things more strict, because this essentially
>> eliminates
>> > > the only "somewhat reasonable" case of trailing characters. The RFC
>> > already
>> > > mentions two of them:
>> > >
>> > > a) We can hard reject "123foo" inputs to "int" arguments (and some
>> other
>> > > places). Currently this is allowed with a notice. I think if we
>> resolve
>> > the
>> > > trailing whitespace question, then there cannot be any reasonable
>> > > opposition to this change.
>> > > b) My own RFC on number to string comparisons would benefit from this.
>> > From
>> > > initial testing it has surprisingly little impact, but one of the few
>> > cases
>> > > that turned up was this comparison with a string that had trailing
>> > > whitespace.
>> > >
>> > > Personally I think both of those changes are a lot more valuable than
>> a
>> > > stricter numeric string definition without leading/trailing
>> whitespace.
>> >
>> > I'm kinda unsure how to go forward because of these points. I would like
>> > to see improved comparisons, and I would like to see the end of the
>> > “non-well-formed” numeric string, and I think this whitespace RFC could
>> > be helpful to both. But I can't see the future, I don't know whether
>> > people will vote for removing leading or permitting traiing whitespace
>> > and whether or not they will be influenced by or this will influence
>> > opinion on the further improvements. ¯\_(ツ)_/¯
>> >
>> > I'm torn between:
>> >
>> > * Vote on allowing trailing whitespace
>> > * Vote on disallowing leading whitespace
>> > * Vote on which of those two approaches to go for
>> > * Trying to bundle everything together and voting on it as a package.
>> >
>> > I'm probably thinking too strategically.
>> >
>> > Andrea
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[Michał Brzuchalski]

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 something in RFC. Usage in key preserved array
expression is not covered and the RFC doesn't describe how it would behave.

Thanks for the efforts on it

BR,
--
Michał

czw., 4 kwi 2019, 16:15 użytkownik CHU Zhaowei  napisał:

> 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 operator consistent. I have also added Q&A
> to explain the questions I received.
>
> Thanks & best regards,
> CHU Zhaowei
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Question about adding !function_identifier

[Sara Golemon]

> 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 along the lines of the following (with runtime checking included),
then I could get on board:

1) function foo(): type noexcept {...}
and/or
2) function foo(): type throws(Type) {...}

I don't even expect the runtime checks would hurt the happy path much since
we already have a check for active exceptions during the function unwind,
and once we know we have an exception, we're in the sad path and an extra
millisecond to check the exception type isn't going to break the bank.

I would say that any exception thrown in (1) should lead to an non-zero
exit since the program has violated an invariant assumption. Similarly if
an exception which is not of type "Type" in (2) should do the same.  2
should (arguably) allow for union typing the way catch does.  (e.g.
 throws(Foo | Bar | Baz)

Basically, the problem with this proposal IMO is that it doesn't go nearly
far enough, and that a single character modifier is unhelpful compared to
something actually readable.

-Sara

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[M. W. Moe]

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 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, Andrea Faulds  wrote:
>
> > Nikita Popov wrote:
> > > I'm always a fan of making things stricter, but think that in this
> > > particular case there are some additional considerations we should keep
> > in
> > > mind.
> > >
> > > 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 is thus mostly backwards compatible.
> Doing
> > > the reverse change is certainly not compatible and will be a much
> harder
> > > sell.
> > >
> > > 2. I believe that a large part of the motivation here is that by making
> > the
> > > numeric string definition slightly more lax (in a consistent manner),
> we
> > > can make *other* things more strict, because this essentially
> eliminates
> > > the only "somewhat reasonable" case of trailing characters. The RFC
> > already
> > > mentions two of them:
> > >
> > > a) We can hard reject "123foo" inputs to "int" arguments (and some
> other
> > > places). Currently this is allowed with a notice. I think if we resolve
> > the
> > > trailing whitespace question, then there cannot be any reasonable
> > > opposition to this change.
> > > b) My own RFC on number to string comparisons would benefit from this.
> > From
> > > initial testing it has surprisingly little impact, but one of the few
> > cases
> > > that turned up was this comparison with a string that had trailing
> > > whitespace.
> > >
> > > Personally I think both of those changes are a lot more valuable than a
> > > stricter numeric string definition without leading/trailing whitespace.
> >
> > I'm kinda unsure how to go forward because of these points. I would like
> > to see improved comparisons, and I would like to see the end of the
> > “non-well-formed” numeric string, and I think this whitespace RFC could
> > be helpful to both. But I can't see the future, I don't know whether
> > people will vote for removing leading or permitting traiing whitespace
> > and whether or not they will be influenced by or this will influence
> > opinion on the further improvements. ¯\_(ツ)_/¯
> >
> > I'm torn between:
> >
> > * Vote on allowing trailing whitespace
> > * Vote on disallowing leading whitespace
> > * Vote on which of those two approaches to go for
> > * Trying to bundle everything together and voting on it as a package.
> >
> > I'm probably thinking too strategically.
> >
> > Andrea
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

[PHP-DEV] PHP 7.2.17 Released

[Sara Golemon]

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 binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: http://php.net/releases/7_2_17.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.17

Many thanks to all the contributors and supporters!

Sara Golemon, Remi Collet

Signatures and hashes may be found below and at:
https://gist.github.com/sgolemon/cf4777b29231cd766626ac13ea8eadb2

php-7.2.17.tar.gz
SHA256 hash:
e1c6c2553cdb7edbfa65b89e259690ed01b31b12d57349c90b6ed00a410f62b5
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJco49UEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJz2hAA
2zaMlRyK6f1oyFsLFbzzJqPcv1jHpIgs20ryIggtMuBBTw0BCX0jnXU1LM5JBE8B
kG1C1goPDOkF7GmmD1Heep2TaIPm+t33qWRT1XgbK83PK6aiAoIrmSovou6dYd2W
gDB7uExhWYzm58HlYdmDnaGM9Lr8ebnC8UWYztCXQYFR/8RaLwgo2D/JLONph9Cu
+knxBojxBjQdsBgkTjo5c5c4Dln1+G7xtAURFGj58eo0SnC3sxVNspX4G38Ipz31
ZGpfr+46VWBRiWxMqZB885aUUTj1pnY2JnmdAVAmNSuNJT6gaw92CrAR0idDfKVW
d0u+lRDCxVLWCtOmJtCpFyHRj2Ow6R81ukSREGUDtyROx+iCDorueE1/CqY0l1Cb
JGQnxgaI1S+BZlXSlBt5ZscA/neqseIf6MrTaenX3rIGQXQaZtQuc8HyvBkLxIE7
AcnK5ZKZJvayKAeEg35U6HWKeKMXrx9GNgSbDQ0UHmpvhTCdhA77SXqH4UgMthy9
LI6UcC7dNVgn+5yFVltLq+V42tDRcISf4X6x3y5cxYFbaiI7CUHx4q0TGjLGHEDT
PbRRc6KGKyjmJ86NEkYxgNdYpbzIsck5HZM6mbcmrNexONimXAI8oIUxWx9tk3hq
M422JDZpmX7Tt5Z+TYMTjyAxFY7bm9Y/v+UuvNa2h7g=
=dAoz
-END PGP SIGNATURE-

php-7.2.17.tar.bz2
SHA256 hash:
91a811ab6f6d7acb312159cf6b0a3cffe968676fdebf042e9253245cc6094f75
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJco49XEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXIk7A/9
FwSjRk/MBYppp8fdT00nr7sraALt24OH3NR4EK4zUxlRv/FaJ6OlM8Pt7lXUQxT5
gn1ZbxxQXcNY6+ngy1nzaCXO1pLlCa4vYb2Q7r7fhBs/BghFGhnGAsh04nVCmOT1
sx3UlhwSnEqPTDwKKUyyCje7A+7nKDe8Oxdeq4hqBw1eReri0OiwP6xL+zIuIIfg
L/W6ffHdC5h6BOxOQOgWxFKgtjw1W5Iy93zb0B4hjkSt+0IGih24mMEjlLVjTgnO
Eps5HJOsBEFIkIpZNAam/msuWbXsaKEpC4UVHkLM5hSA/rad4NxC8rfuxMtIOcCM
9TQ0LqLq73r3C6atumS6sDj3rpKlwfEHlSVzJBUQoQtibSbd1C3HyU3RsDz4AVPr
eAtQNi1mD60o6wucGJT0MpStQlaDgPoZ4JvKpvV1lDpuVdJkxbZsKPHFD/yyC02n
ZxXnuAJRJyH5D8iqjyhWVqvFiF37vpREam96loa2S2b3uujoor0nmFUQKWWkaJ6h
PAA7xi4f5WKp5VknxtFBGj7XQS3BS8t5RasXXe/1BYybr+mIpG4IzrA2mk5WF7JV
aQV9zZkzOOkdwhBC15su+0MRWWS4z7zTYFhWw2yLjku6V/tQz3N5iJFzNUk/H0BQ
1FkC2qCeCD3CN1c0JomhMgSACv/375lJQLv6QgwgdVA=
=zNrM
-END PGP SIGNATURE-

php-7.2.17.tar.xz
SHA256 hash:
a3e5f51a9ae08813b3925bea3a4de02cd4906fcccf75646e267a213bb63bcf84
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJco49XEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJecA/+
N/76/I91j/DcevNQBCp8LLR4wDmkO0lPWW6PAOol2KIYBpKj3/fG4DyO5rGVzgYO
qKZFy5h5PrRVGuMWnhyHZ+nAy/owgSdI01YBDFSqoTrJy3PiHbtINrzsoTdG60+Q
3zaljoNbxR5+9sMviWViKBEFAdLeGqNgKkxXEe/KGXiV91Wc51VbxwswIuhVHVzy
yyd5VDMh2FuWfN5tZdZjNx9OPL6nxd5PcESdaFPBB2w2lFeRGXDT08KtM/iKKqpV
PlUoVR23PWDLkU1ZhDuaD6P78nP/q2a+zaF41hSH+YObN7g/A7YtzaQ1bmikDj5l
NFiigJfcn+7ZtXGNaidx4VTak9LcztE17TUUcLqzB9M/m5G3QaNCTfYQGQhqaWR7
4h5q7oqJDN01mejmu9L9UAiRCqFIeDUiANgAtVbdq2ZF/zrDBEVTSedFKUJjDdZi
nahacXq6EJaXIGMxEszKoxTXIxgrgL+5In91JBzT8hK0pPuCZYS1zze1lrBeLogm
OjR3Tiz1SGJ6q32VaoE/MLClBt27mdrqStDIZ3VGuVyRuucdGg33TVhqeTKSSPi8
f2XdG/+cBnkqCy/xrxRe6sXXm9vu0ugYXvPHxN2tkb+gYK7LwzfTZI5vTxjcuhXx
OPrtL3rJ2ps7aCzQzHSZIaEqpc5j6oUiDVxkMx3C1gc=
=91kj
-END PGP SIGNATURE-

[PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[CHU Zhaowei]

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 operator consistent. I have 
also added Q&A to explain the questions I received.

Thanks & best regards,
CHU Zhaowei 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7.3.4 Released

[Christoph M. Becker]

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 found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: 
Downloads:
Windows downloads:
Changelog:


Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.4.tar.bz2
SHA256 hash:
2e2c3d8212c83649e443b61efffbd03df4b9edd0f9c7a679081fe4cb2da12b78
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAlyjaYsMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2U44P/3dOID0h2cs9KHAkUhc1HIUmD2F1F4awSR3Roxrm
grKUT2WhwZIn61+fidD6KevQUyNEBYQ9W0nhqrhrFEA9ytBSVehCrY8jg9eRCQzs
nzkEz8vQoDIIZs3ZTtdHBK/LGyotEYZhLy2mINaYQ56MbtPrwkymml2uChns2blf
5b8iLjbRLJx1axQ8BEvpoS//H4l70BQ+HrSteCelgUNYRsnVKxrwz+O7tAenaTWf
DEHFe353drX2QQO6XM4hZcU7F3iW5oOZ01Os73cU2HGaxdnxkVsh0/HbJJ7eHisi
aybAjm2GgJHO0Dc2YMgMVQ5DfZdeuj2kW4+zJ4K9cBDm2b2McvFB4zbpOHubKKln
139t4r4+aSukYEvFKhGGccFvzNAxYnpfsH39L9HaWIodK5Bq2g8O4K4Vu7c4vQsf
3+h4vo4DUXbzXWeelLzoyc4Y/3DmltEET23Ci/fiXsdKJ+XZveMIgYCh+r49zNQs
ZY0MEwWYNd/W53Ja5atuJl0mhdNkYmllOUOEt0upyk8zg8jEVBkMUEJ65FWAXt34
6uhNpoNpWVX+/YQ+plSRbHY2XWTVaHTXc8Gytkb0ylEoOj7WK9RLwcdV+jrntCup
iK2/x1vp+zH41jjIeKEkJcBpaYjtdYjpgUGuxTTQ4khaT1vCvPpnWp0LxKYESBIT
5pG0
=jVBE
-END PGP SIGNATURE-


php-7.3.4.tar.gz
SHA256 hash:
dd41ecf43fe1172030f41d2581909457a0af7bd137a057c3874e0b0f3c2e8761
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAlyjaYwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2STIP/3XMYO91X/FtPLgPBm+yEXdCNgvLyVDe2Dk/q799
/aXgx2NpRoqUPh4jGour+5q5wvlQcKOX8SOFDS58oT0UX0C+g8ovtkHBppjhLFf1
52ZV48GYz6sokfFjNt8oWkQWCDLPphuRgoGCRGXQSOfbtncQ+Otk+FZHB8tgXL+D
HvnBXGoAUWdFHzjX8or9yiDZuHizInSBEaGd2qhH9AzA1q48JOw4tYnafZD5VvqZ
6vSlmYpky1RJ9zvpWXesW/IOkw7pSusAm6sAA9E3LX4Er/CofILxa2A7ZDtRvQ4J
IY3Dj49sWaBLbAUYXAtlrdHIvaSGBaHczEGAm2tU6Vhx7de8TPWm+Xdud5g7Kpm3
f1HrKNRwNQy+H2f5jqTRiGShMndIfJrjDbV+eiZp9NnCKJsygBI4Je7pMo5QMi7X
dvTK5KoMreYcXWRH4wlG+57Zx3/X62LJReF9wd3zJIvQfsBjGa3xnZyCu1gBRAbl
Qb++fR/r7o9QXaG2WHCp9NlsGH7glTU1HigxAvOV+P84Qr+2oA0s5IiduuEyfRUy
ltTohb5eJJESqU64avnbLzf8gdW0Ci6lww1luUYnTN78lz6IqC+NOwf/seW6RcRU
u3h8HAL0ha6u3vN4jqSzf147BYqKVWZi7TRZWN1w2M1hvCh6lzqCIgXfAlw1yXsi
WnFr
=mjXm
-END PGP SIGNATURE-


php-7.3.4.tar.xz
SHA256 hash:
6fe79fa1f8655f98ef6708cde8751299796d6c1e225081011f4104625b923b83
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAlyjaYwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2LTkP/1A7JBZgH/eUVDR4m4r/jXwKpbskbJUFlEkno8JP
gt7yry6z1ACsjBK9ffOCZKulT8OE3cz7BAF9fwt1ltpD/9sIXwJqP+W7wgpHQqxt
bY1ToAxO1PWCRpMn45wBbpF0meUpkIDpL7IHg3XK49P3qCFhU68zSuzdRWX1Ncby
BJEgMDmNFNepgkwA3YGddAF5v1FYCUyzkTh2aHnk6V/HqH/8GabxCrzlx37gXxva
HMpKigYUIgdEoYRke95jGVFaHrF6H+YnUZgM6QZqU6cLHwAX+9CadjS1GT3brkhR
sOHEyrdXdIbv+/yB0HGUfgpNVPleEuh3DiveSCRqLPTOSKVPm28R9927Nfzh2t41
B9ojzMiOjQUl5cjD6YNmmOVT1PX/W3jJmSq7FF8py9G4wIze7S+vuoZoQyI/JL6Z
bf92XbbHJoaSu9bJ33jFv14NCRjPhd6C1lzTM6aQ+c6QkgHcYY3K+fOUFpPVFK3E
lZ93YeExiZ4EUK6RyNg0nAsQPGfqw61lQiiHl+hLn8r2l0v+jp9Hhwy/7yIkc/pr
czI/PfQQuiNbtUHIPwGB2uRqHbGD8bmfk2eigpmRftDTXvo1s4QnH/j1TSKXnGYL
bnZt+I0hAQJgsCkB9998S3ADrszhq0+ROCMBQ0tc0tpegBuOC5f1dshse+9uLVrh
Kr5J
=WenD
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[Lester Caine]

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 is thus mostly backwards compatible. Doing
the reverse change is certainly not compatible and will be a much harder
sell.


I think it may be worth pointing out here the distinction at least with 
Firebird and I thought with other databases? A CHAR field is always 
returned padded with spaces to it's length, while a VARCHAR field is 
always trimmed to the last non space character. There are often reasons 
for using CHAR although many of those are probably historic, but 
trimming them without proper consideration is less than ideal. Returning 
historic material where numeric data is right justified in a CHAR field 
is equally valid.


Handling these has always required care and it would be preferable that 
both returned the same result without having to trim and perhaps 
creating problems when the padded version needs to be returned ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about adding !function_identifier

[Benjamin Morel]

>
> 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 2019, at 03:29, M. W. Moe  wrote:
> >
> > Thanks!
> >
> >> On Wed, Apr 3, 2019 at 1:24 PM G. P. B. 
> wrote:
> >>
> >> Hello,
> >>
> >> I don't really see the point of it as you self said this wouldn't add a
> >> runtime check, so in what is it different to a comment?
> >> More so reusing ! for this will, in my opinion, just lead to confusion
> as
> >> people will think it negates the function, this is what
> >> I would expect it to do at first glance.
> >> Also comparing it to the nullable question mark is quite bizarre I find,
> >> why not choose the ampersand for references instead?
> >> At least it would cover the same "scope", as types have nothing to do
> with
> >> how a function behaves.
> >>
> >> Best regards
> >>
> >> George P. Banyard
> >>
>
> 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.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[Benjamin Morel]

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, Andrea Faulds  wrote:

> Nikita Popov wrote:
> > I'm always a fan of making things stricter, but think that in this
> > particular case there are some additional considerations we should keep
> in
> > mind.
> >
> > 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 is thus mostly backwards compatible. Doing
> > the reverse change is certainly not compatible and will be a much harder
> > sell.
> >
> > 2. I believe that a large part of the motivation here is that by making
> the
> > numeric string definition slightly more lax (in a consistent manner), we
> > can make *other* things more strict, because this essentially eliminates
> > the only "somewhat reasonable" case of trailing characters. The RFC
> already
> > mentions two of them:
> >
> > a) We can hard reject "123foo" inputs to "int" arguments (and some other
> > places). Currently this is allowed with a notice. I think if we resolve
> the
> > trailing whitespace question, then there cannot be any reasonable
> > opposition to this change.
> > b) My own RFC on number to string comparisons would benefit from this.
> From
> > initial testing it has surprisingly little impact, but one of the few
> cases
> > that turned up was this comparison with a string that had trailing
> > whitespace.
> >
> > Personally I think both of those changes are a lot more valuable than a
> > stricter numeric string definition without leading/trailing whitespace.
>
> I'm kinda unsure how to go forward because of these points. I would like
> to see improved comparisons, and I would like to see the end of the
> “non-well-formed” numeric string, and I think this whitespace RFC could
> be helpful to both. But I can't see the future, I don't know whether
> people will vote for removing leading or permitting traiing whitespace
> and whether or not they will be influenced by or this will influence
> opinion on the further improvements. ¯\_(ツ)_/¯
>
> I'm torn between:
>
> * Vote on allowing trailing whitespace
> * Vote on disallowing leading whitespace
> * Vote on which of those two approaches to go for
> * Trying to bundle everything together and voting on it as a package.
>
> I'm probably thinking too strategically.
>
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>