Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Rowan Collins
Andrea Faulds wrote on 14/10/2015 22:52: Good evening, I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! My feeling is that it is odd to have both of these be true at once: - void functions can

[PHP-DEV] PHP 7.0.0RC5 is available

2015-10-15 Thread ab
Hi, The fifth release candidate for 7.0.0 was just released and can be downloaded from: https://downloads.php.net/~ab/ The Windows binaries are available at http://windows.php.net/qa/ This release contains fixes for 11 reported bugs and over 100 commits with various improvements.

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Chris Riley
On 14 October 2015 at 22:52, Andrea Faulds wrote: > Good evening, > > I'm reviving my Void Return Type RFC, this time for PHP 7.1: > > https://wiki.php.net/rfc/void_return_type > > Please read it and tell me your thoughts! > > Thanks. > > P.S. As it so (fatefully?) happens, I

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Björn Larsson
Den 2015-10-14 kl. 21:25, skrev Sammy Kaye Powers: Hello internals friends! I'd like to open a discussion on the RFC to allow trailing commas in function arguments. https://wiki.php.net/rfc/revisit-trailing-comma-function-args Discuss! :) Thanks, Sammy Kaye Powers sammyk.me Given the

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Björn Larsson
Den 2015-10-14 kl. 23:52, skrev Andrea Faulds: Good evening, I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! Thanks. P.S. As it so (fatefully?) happens, I originally introduced this on 14th

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Alex Munkelwitz
Just my own opinion, but I support this idea. For most functions it may be out of place, but when dealing with variadic functions it can add consistency to code. In addition it can make for cleaner diffs when overriding or switching back to default arguments. It is nice to not need to adjust

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Rowan Collins
Korvin Szanto wrote on 14/10/2015 23:55: If I capture the result of a "void" method and check if my result variable with isset(), I'll get false. This sounds like it's void of value to me. But why "invent" (as far as PHP is concerned) this new keyword of "void" to mean exactly the same thing

Re: [PHP-DEV] Port random_bytes to PHP 5

2015-10-15 Thread Pierre Joye
On Oct 14, 2015 4:06 PM, "Sebastian Bergmann" wrote: > > On 10/13/2015 04:59 PM, Anthony Ferrara wrote: > > Overall, I don't think this should be ported back to 5.x > > +1 Same here. There are working solutions already for 5.4+, for example openssl rng functions and compat.

[PHP-DEV] Benchmark Results for PHP Master 2015-10-15

2015-10-15 Thread lp_benchmark_robot
Results for project PHP master, build date 2015-10-15 05:12:36+03:00 commit: 2951ed33e7521cc9b10dcc2ba13e065ff943f72d revision date: 2015-10-15 00:55:52+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Rowan Collins
Andrea Faulds wrote on 15/10/2015 16:32: Hmm, this is an interesting case you've pointed out. Being able to do `return some_other_void_function();` is something I've desired in other languages. But what if that void function you're calling later adds a return value? Now the calling function

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hi Rowan, Rowan Collins wrote: I can see the point in denying the right to say "return some_function_expected_to_return_null();" But in a sense this is no different from declaring that a function returns int, and then writing "return some_function_expected_to_return_int();" If a void function

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Rowan Collins
Andrea Faulds wrote on 15/10/2015 16:32: Hi Rowan, Rowan Collins wrote: But why "invent" (as far as PHP is concerned) this new keyword of "void" to mean exactly the same thing "null" already means - absence of a definite value? They don't mean exactly the same thing. null is a value to

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hi Rowan, Rowan Collins wrote: But why "invent" (as far as PHP is concerned) this new keyword of "void" to mean exactly the same thing "null" already means - absence of a definite value? They don't mean exactly the same thing. null is a value to represent a lack of a value. But there's also

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Pedro Cordeiro
I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. $a = $b; //$b wasn't initiated. This does the same thing. I tried accessing what was supposed to be

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hey Chris, Chris Riley wrote: Semantically, I don't believe that there is sufficient difference between "returns no value" and "returns a value which has been defined as having no value" for us to care about it. The main difference you get between return type of null and a return type of void

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hi Larry, Larry Garfield wrote: On 10/14/2015 06:30 PM, Andrea Faulds wrote: This would be strange. The manual doesn't say `null`, and I can't think of any language which uses `null` as the return type in this situation, even when they have the same implicit-null-return behaviour that PHP has

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Marc Bennewitz
On 10/15/2015 01:19 AM, Larry Garfield wrote: On 10/14/2015 06:00 PM, Andrea Faulds wrote: >> Both you and Stas have said this, but it's only true if we solely >> consider C-like languages. Other languages do different things. In >> the PHP manual, Hack, TypeScript, ActionScript, and most

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Marcio Almada
Hi, 2015-10-14 16:25 GMT-03:00 Sammy Kaye Powers : > Hello internals friends! > > I'd like to open a discussion on the RFC to allow trailing commas in > function arguments. > > https://wiki.php.net/rfc/revisit-trailing-comma-function-args > > Discuss! :) > > Thanks, > Sammy Kaye

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Sara Golemon
On Thu, Oct 15, 2015 at 1:08 PM, Nikita Popov wrote: >> I would say that it should be modified to disallow a trailing comma >> following either a variadic declaration or a splat invocation, since >> the grammar around these two things prohibits followups anyway. > > > We

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Rowan Collins
On 15 October 2015 20:33:04 BST, Andrea Faulds wrote: >> Obviously, type hints for internal functions are a bit weird anyway, >but >> there's no reason to assume that every function documented as void >would >> suddenly be annotated in the Engine as such and start returning >notices.

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Korvin Szanto
On Thu, Oct 15, 2015 at 4:21 PM Rowan Collins wrote: > On 15 October 2015 20:33:04 BST, Andrea Faulds wrote: > >> Obviously, type hints for internal functions are a bit weird anyway, > >but > >> there's no reason to assume that every function documented as

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hi Korvin, Korvin Szanto wrote: Could we change the documentation for existing functions to return null, and start using void properly moving forward? As I have stated several times now, we're not "misusing" void. PHP is not the only language to use the word in this manner. But why

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

2015-10-15 Thread Stephen Coakley
On 10/08/2015 04:14 PM, Larry Garfield wrote: On 10/01/2015 01:59 AM, Stephen Coakley wrote: So then, in summary, threads & multiprocessing enables you to do more *work* simultaneously, while async **maximizes the usefulness of each thread you have**. So using both is actually an incredibly

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Ryan Pallas
On Thu, Oct 15, 2015 at 1:46 PM, Sara Golemon wrote: > On Thu, Oct 15, 2015 at 12:16 PM, Ryan Pallas > wrote: > > But its an entirely stylistic choice to use trailing commas for cleaner > > diffs. You could also use leading commas as well. If you made

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Nikita Popov
On Thu, Oct 15, 2015 at 10:04 PM, Sara Golemon wrote: > On Thu, Oct 15, 2015 at 12:51 PM, Ryan Pallas > wrote: > > I do h ave one question I just thought of though... how does the > allowance > > of trailing comma work with the splat operator (...)? I'm

Re: [PHP-DEV] [RFC] Arrow Functions

2015-10-15 Thread Björn Larsson
Den 2015-10-03 kl. 01:17, skrev Levi Morrison: I messaged the list about this feature before I had the RFC written up for it. The RFC[1] is slightly different from what I proposed in the previous thread, so please read the RFC to make sure you understand what is being proposed before replying

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Sara Golemon
On Thu, Oct 15, 2015 at 12:51 PM, Ryan Pallas wrote: > I do h ave one question I just thought of though... how does the allowance > of trailing comma work with the splat operator (...)? I'm assuming a > function call/definition may only have one or the other, is that

Re: [PHP-DEV] PHP 7.0.0RC5 is available

2015-10-15 Thread Michael Kliewe
Hi guys, Am 15.10.2015 um 13:26 schrieb a...@php.net: This release contains fixes for 11 reported bugs and over 100 commits with various improvements. Now we've managed to resolve the last of the outstanding issues. Let's help PHP 7.0 along to emerge from its pre-release shell the most

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hey Chris, Chris Riley wrote: Semantically, I don't believe that there is sufficient difference between "returns no value" and "returns a value which has been defined as having no value" for us to care about it. The main difference you get between return type of null and a return type of void

[PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hi everyone, Andrea Faulds wrote: I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! Since the void/null naming issue has been a frequently-asked question, I've added a subsection to the RFC

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hi Pedro, Pedro Cordeiro wrote: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. We could do this, but I do wonder if it might cause a lot of E_NOTICEs

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Chris Riley
On 15 October 2015 at 16:32, Andrea Faulds wrote: > In a sense, what this RFC offers might be called a compromise. It enforces > the rules of `void` within the function, but at the end of the day the > caller still gets a null out of it since that's what PHP's always done. > > > If

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Pedro Cordeiro
> > this would make the "void" keyword feel more meaningful. I, too, had issues trying to understand what "void" was bringing to the table. IMHO, it should warn people thinking some specific function/method returns a value when it doesn't, not protect against some dev forgetting the function

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Sara Golemon
On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson wrote: > Given the reason against this RFC in the thread it would be interesting > to know why HHVM decided to implement it? > Happy to answer, but I need to state a couple things first: * I don't really care if this

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Rowan Collins
Pedro Cordeiro wrote on 15/10/2015 17:14: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. $a = $b; //$b wasn't initiated. This does the same thing. I

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Rowan Collins
Andrea Faulds wrote on 15/10/2015 17:34: Hi Pedro, Pedro Cordeiro wrote: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. We could do this, but I do

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Björn Larsson
Den 2015-10-15 kl. 09:04, skrev Björn Larsson: Den 2015-10-14 kl. 23:52, skrev Andrea Faulds: Good evening, I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! Thanks. P.S. As it so (fatefully?)

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Pedro Cordeiro
> Wouldn't this give the same benefit as trailing commas when it comes to > adding removing arguments - a single line diff? It would. However, I see some merit in someone wanting trailing commas for diffs. Leading commas would break away from PSRs and one should not have to choose between a

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-15 Thread Andrea Faulds
Hi Rowan, Rowan Collins wrote: Andrea Faulds wrote on 15/10/2015 17:34: Hi Pedro, Pedro Cordeiro wrote: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Sara Golemon
On Thu, Oct 15, 2015 at 12:32 PM, Pedro Cordeiro wrote: > I see no reason to allocate resources to make this happen, but if someone > does allocate their personal time into coding this, I wouldn't oppose a > merge. > There's a diff attached to the RFC. The actual

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Sara Golemon
On Thu, Oct 15, 2015 at 12:16 PM, Ryan Pallas wrote: > But its an entirely stylistic choice to use trailing commas for cleaner > diffs. You could also use leading commas as well. If you made that a coding > standard for the organization, you would not have needed to

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Ryan Pallas
On Thu, Oct 15, 2015 at 1:32 PM, Pedro Cordeiro wrote: > > Wouldn't this give the same benefit as trailing commas when it comes to > > adding removing arguments - a single line diff? > > It would. > > However, I see some merit in someone wanting trailing commas for diffs.

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Björn Larsson
Den 2015-10-15 kl. 19:14, skrev Sara Golemon: On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson wrote: Given the reason against this RFC in the thread it would be interesting to know why HHVM decided to implement it? Happy to answer, but I need to state a couple

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

2015-10-15 Thread Ryan Pallas
On Thu, Oct 15, 2015 at 11:14 AM, Sara Golemon wrote: > On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson > wrote: > > Given the reason against this RFC in the thread it would be interesting > > to know why HHVM decided to implement it? > > > > Happy to