Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 reason against this RFC in the thread it would be interesting to know why HHVM decided to implement it? Regards //Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 February, and it's now 14th October, so it's been exactly 8 months! Thanks! I have been waiting for this RFC to reopen. Actually wondered why void wasn't among the reserved words in the https://wiki.php.net/rfc/reserve_even_more_types_in_php_7. Regards //Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 other lines of code when removing one. Those are pretty minor gains, but I think they outweigh the minor code cruft that this could introduce. I appreciate that php allows trailing commas in arrays and I don't think there's a compelling reason to avoid making functions consistent with that behavior. -alex On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson wrote: > 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 reason against this RFC in the thread it would be interesting > to know why HHVM decided to implement it? > > Regards //Björn > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 "null" already means - absence of a definite value? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 originally introduced this on 14th > February, and it's now 14th October, so it's been exactly 8 months! > > -- > Andrea Faulds > http://ajf.me/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Hi, 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 seems to be some extra fatal errors, for a developer there seems little value. >From a user confusion point of view; PHP currently considers return; and return null; to be equivalent (in fact some code style checkers will replace one with the other) If (and only if) a function has a return type of void these two statements are no longer equivalent - one is a fatal error one is not. For any other return type specification, return null; and return; would behave the same. This in itself would be enough for me to be against adding a return type of void. (also could someone enable my wiki acc: carnage; sent an email ~a week ago and haven't heard back yet :() ~C
[PHP-DEV] Benchmark Results for PHP Master 2015-10-15
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 mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0beta3, with hash 1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00 -- benchmark relative change since change since std_dev* last run baseline -- :-) Wordpress 4.2.2 cgi -T1 0.14% -0.19% 2.61% :-) Drupal 7.36 cgi -T1 0.94% -0.17% 1.42% :-) MediaWiki 1.23.9 cgi -T5000 0.30% -0.49% 2.37% :-) bench.php cgi -T1 0.05% -0.73% 2.17% :-| micro_bench.php cgi -T1 0.02% -0.70% 0.41% :-(mandelbrot.php cgi -T1 0.20% -2.65% 2.58% -- Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. * Relative Standard Deviation (Standard Deviation/Average) Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 appear in expressions, where the return value is
interpreted as null
- "return;" and "return null;" are no longer treated as equivalent
If the intent is to say "you can use this in an expression, but its
value will always be null so there's no point", then "return null;"
seems just as valid as "return;", and a typehint of "null" seems to make
more sense.
I take the point about making intent clear, but can't think of any other
interpretation of "this function always returns null" than "this
function has no meaningful result". In other words, I can't imagine
ever wanting to use "null" to mean something different from "void" in
this context.
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 can be used in an expression, it can be used in a
return expression, and if so, it feels natural for the type hint to
propagate:
function foo(): void { do_something(); }
function wrapped_foo(): void { do_something_else(); return foo(); }
// ERROR: can't specify return value in a void function
"return foo()" is not illegal because foo is declared void, but because
wrapped_foo is - even though the result is exactly as expected.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 7.0.0RC5 is available
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. 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 effective way - by investing even more into stronger testing and verification of the critical points. Stability matters more than ever. We're on the finishing straight, hold on tight! Please test it carefully, and report any bugs in the bug system. The next scheduled release is going to be tagged on October 27th and released on October 29th. It will be RC 6. Below is the verification information for the downloads: php-7.0.0RC5.tar.bz2 SHA256 hash: 90e3f91c6781e6cdd198dd7b3f9bceff0c00be74a56ea0940b4ad9c6b312b4db PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJWHn3XAAoJELyqMOqcDVdjVL4H/jXOiXyHfF4P4YBiDQW2I7mY WNm+kStAFkYvZQv8xaMEdJMB9M0ekQB63Xz5qRY8ONWhlpWlgy210GGRpBtsAHcy DZpdYHrCBPM4yR4hjEB9PB8HlZqu/RO4MrjOXbk40aLF/BegwsIagC4kKoR/Zrqn blKYFMP+A9YF1BmqU+RWcuO/NZLVkThPgmKAjS4vaEH72v/IC5SywDI56kSFgkhV dOSAXPZsWne7nrrCf2tAcJsieaWDdhInpnKCKAwMEegJa7byGUhUQHYbRTwtKdg8 VJgcm7NewwNU2PgIWEBqs6fMVJdawBthj10cGbrG0ZLG4miBdf+RFKFGQj/wgRY= =6T2p -END PGP SIGNATURE- php-7.0.0RC5.tar.gz SHA256 hash: 4e8a76efb356d1068b502daed3c1c87f95ec404164a9b20068552bd12f9da10f PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJWHn3aAAoJELyqMOqcDVdjCVAH/RcAtBa+gsW6Bgsu16/FQFl/ qXkDDC0SCmtoukscv5BmtBNtFXYlf4bNBfK7ZqTC5JSaWdyGRpPIwi/QUy5qSfLF IbHTk7ZDHRkGXCYSb6vRDiZh7L80zGEZduD8SpQ7Afm3mDltGVEoCvs95UhuumXG 0XPQeAnxBPdMSmFSIX8nNuFgmfYPJ54pqmt9jCYbe9n/ZkDMGmDljamygMHGgzyk 68tQRermYTgsrGdWjLYmlehf4aIc3GAZFFDu9SBp4I+82FIihB14J90g5ZKWEhKk VUE0gv2MnLV1OCJ8YCs+HOM/L3lSVfrK1mhTxnDk/2ZbgjHNzFXUZs84dfks3fM= =y8Vv -END PGP SIGNATURE- php-7.0.0RC5.tar.xz SHA256 hash: 4625237fc6927df5792f1ebf2c267cebf6c1855fe4c37db4a6dcbad7a5d14be4 PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJWHn3dAAoJELyqMOqcDVdj7+AH/jcyQN4bTIWYvXez1Er/7aZ9 gzI0CUdb70px7WEPhP2OsOLe9v3osyfkTem1tmJPAYMUJJKaBG2zP81GvBcuis/z 6bx1iH0qifpsp1ydRtyAaCuVDOgT8wOQ63+dZUm3FC7jrZrxldv/a19URKr9V5Vz QWDa4kIrtGFFnmcdtEEoqHbOba+9KR26+NcmdbJj0GQFNJRMwVgcsqeRVv7f2i3z YZcsZDlFlw/A/rknjAf9ewnBqEDsz9mflCWyN81uDRh+8yNxvPQLMXEqrnveS4eG wQd6cFXL2dp5UM5jJ+QTtDYD4LxUtUc86Y+11GUIpAgnb6DiQD00kfPG/0j4vTk= =aWLo -END PGP SIGNATURE- Regards, Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 likely
other >> languages (these are just off the top of my head), `void`
functions >> do still have an implicit result. >> >> All of these
languages would have had the choice to do what you're >> suggesting and
use `null`, or its equivalent (`undefined` for >> TypeScript and
ActionScript). They didn't. Why? If I had to guess, >> there's at least
three reasons. For one, void is the word languages >> usually use for
this. For another, `void` and `null` they mean >> different things.
`void` signifies a function isn't returning >> anything. `null`
signifies a function that *returns null*, regardless >> of where that
null came from. `function foo(): null { return >>
some_probably_null_returning_function(); }` should surely be legal >>
with a `null` type hint, yet it's nonsensical code. Finally, making a >>
function truly "return nothing", i.e. disallowing its use as an >>
expression/rvalue, breaks some use cases, like passing along the >>
result of a callback. >> >> PHP would neither be the first nor the last
to be using `void` in >> this way. >> >>> If the union types RFC[2]
passes it >>> makes sense to allow `Foo | null` which allows something
of type `Foo` >>> or `null`. To me it makes sense that if you then
remove `Foo` you are >>> left with `null`, not `void`. My personal
recommendation because of >>> this would be to use `null` for the return
type and instead of `void`. >> >> `null` would be a weird type, because
it doesn't make sense as a >> parameter type, and as a return type, you
don't really want to >> enforce returning null, you want to enforce not
returning at all (see >> the example above). It feels like a poor man's
substitute to me. >> >> Thanks. > > The tricky part here is that saying
a function does not return is not > something PHP currently does: > >
https://3v4l.org/HtAuC > > No return implicitly returns NULL, which you
can assign to a variable > if, for some strange reason, you were so
inclined. So this would be > more than "just" a syntactic documentation
feature. > > Which I believe gives the following options: > > 1) Change
the language behavior such that > > function foo() : void { ...} > $a =
foo(); > > Is a syntax error (because there really was nothing returned
to > assign), rather than resulting in $a having a value of NULL. > > 2)
Use null as a "type" (which I agree feels weird just saying it), > such
that: > > function foo() : null { ...} > $a = foo(); > > and > >
function foo() { ...} > $a = foo(); > > are identical. The former would
impact the contents of the function > (eg, a non-empty return would be a
parse error), but the external > result is the same ($a == NULL). > > 3)
Use the "void" keyword, but give it the same effect as option 2. > > The
RFC currently seems to propose option 3 (based on the "Use of void >
functions in expressions" section). I don't have a strong feeling at >
this point about which option I'd prefer. >
Option 4)
// implicit return void
function foo () { return; }
// explicit return void
function foo () : void { return; };
// syntax error if returning something on explicit return void
function foo () : void { return null; };
// syntax error on using return value of explicit return void
function foo () : void { return; };
$bar = foo();
// return NULL on implicit return void (this could also give a
warning/notice/deprecated error)
function foo () { return; };
$bar = foo(); // NULL
// mixing return void with any other return values could also result in
a warning/notice/deprecated error
function foo () { if ($bar) return; return $bar; };
--Larry Garfield >
I really like this as in my opinion if a function doesn't return
something it should be part of the function signature and it really
helps to avoid mistakes on writing code.
Marc
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 seems to be some extra fatal errors, for a developer there seems little value. From a user confusion point of view; PHP currently considers return; and return null; to be equivalent (in fact some code style checkers will replace one with the other) If (and only if) a function has a return type of void these two statements are no longer equivalent - one is a fatal error one is not. For any other return type specification, return null; and return; would behave the same. This in itself would be enough for me to be against adding a return type of void. This is true, but `void` isn't an ordinary return type. It exists to ensure a function doesn't return anything, unlike other return types which exist to ensure a function returns a specific thing. `return null;` is *technically* equivalent to `return;`, but it's not quite the same in intent, usually. We could special-case it and allow it, but why? The return value isn't supposed to be used, why should we allow you to specify it? A void function in PHP does technically produce a result of null, but it might as well be false or -1 or whatever for all we care. Also, if `return null;` is to work, should `return(null);` also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It seems silly to me since, again, the return value is insigificant. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 can be used in an expression, it can be used in a
return expression, and if so, it feels natural for the type hint to
propagate:
function foo(): void { do_something(); }
function wrapped_foo(): void { do_something_else(); return foo(); }
// ERROR: can't specify return value in a void function
"return foo()" is not illegal because foo is declared void, but because
wrapped_foo is - even though the result is exactly as expected.
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 is returning a value other than null, violating
its type hint and producing a runtime error.
It's a shame there's no "tail call this other function and discard its
result" construct.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 the concept of *no value at all* (a missing variable, say). The closest we have to that in PHP already would actually be `unset`, but that's a strange choice given it's not what we use in documentation (function prototypes, PHP manual, PHPDoc, etc. use `void`), and it's tainted by the bizarro `(unset)` cast which casts to null. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 (see the email you're replying to). Also, wouldn't you expect this to behave like existing type hints, and let you return a null value from any source? But that's not what you would actually want, right? Thanks. Well, that depends on the intent here. In practice, is the intent to add a "no return at all" type of function (ie, $a = foo() is a syntax error now where it was not before), or to make it explicit that the only legal return is null (even if implicitly that means having a non-early return statement is pointless)? Those are the two options. That may or may not dictate the keyword that gets used. It would seem ideal to have "true" void functions which can't be used as expressions, i.e. producing an error if you try to use them like in your example. But they'd cause a backwards-compatibility headache, and I'm not sure they're a good idea anyway. Every function call being an expression is pretty handy. You can safely capture the return value of a callback and pass it along, for instance. 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. It definitely sounds like you're favoring the second (as that's what the RFC says). Which may or make not make "void" an odd keyword to choose when what's actually happening is NULL getting returned. Is NULL a void? (There's a deep philosophical question...) It's an interesting question. There's some precedent for using `void` in this way even though the functions aren't "truly" void. I mostly like `void` because it's the customary keyword to use, though. Everyone knows what a 'void function' is. As I said, I don't have a strong opinion on the subject yet. I'm just trying to distil the discussion down to as small a question as possible. :-) I appreciate your efforts. I have a tendency to be a bit verbose in my writing, so providing clarity is helpful. :) Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 is returning a value other than null,
violating its type hint and producing a runtime error.
Well, fundamentally, this is true of anything short of full
type-checking. The type safety below is self-evident:
function foo(): int { return 42; }
function wrapped_foo(): int { return foo(); }
But foo() could later be changed to this:
function foo(): string { return 'The Answer'; }
The wrapped_foo() typehint is now broken. That's not really any
different from foo() starting off as void/returns-null and adding a
return value.
In both cases, a static analyser could detect the discrepancy, but the
Zend Engine will not, until the function is executed.
It's a shame there's no "tail call this other function and discard its
result" construct.
Yeah, I guess what you really want is for a void function to be able to
"goto foo();"
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 represent a
lack of a value. But there's also the concept of *no value at all* (a
missing variable, say). The closest we have to that in PHP already
would actually be `unset`, but that's a strange choice given it's not
what we use in documentation (function prototypes, PHP manual, PHPDoc,
etc. use `void`), and it's tainted by the bizarro `(unset)` cast which
casts to null.
Oh, lord, not this discussion again! PHP has no concept of a variable
being in the "state" of unset; it has programmer hints to warn you if
you read before writing, and a couple of odd constructs which let you
access the current symbol table as a dictionary.
The manual has some weird wording in places which implies that a
variable takes on a type when first used, but in practice the rule is
much simpler: any variable which hasn't had a value assigned yet is
considered to have the value NULL, and normal cast rules apply from
there. The same is true of missing array keys, object properties,
unset() variables, unspecified return values, etc, etc, etc. They are
all NULL.
You could add a warning for "function foo() { return; } $a = foo();" to
match "$x = []; $a = $x['foo'];", but $a would still unambiguously
contain the value NULL in both cases, and outside of some odd
applications like templating, it is *values* the program should be
concerned with, not the *reason* for those values.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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
'nothing' ($b), and got NULL with an E_NOTICE being thrown.
function myFunc() : void { ... }
$a = myFunc();
I see no reason why this should silently assign NULL to $a, *specially* with
"return null;" being explicitly forbidden.
My point is: we already use an implicit NULL return on functions with
missing return values (or with "return ;"), but now we're explicitly
prohibiting even a NULL return. The behaviour should be consistent (NULL
should be accessed, as for all undefined things), with an E_NOTICE.
function myFunc() { return ; }
$a = myFunc();
Should assign NULL to $a and *not* throw an E_NOTICE (this is the current
status), because a return type was not forbidden with the keyword 'void'.
2015-10-15 13:00 GMT-03:00 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 is returning a value other than null, violating
>> its type hint and producing a runtime error.
>>
>
> Well, fundamentally, this is true of anything short of full type-checking.
> The type safety below is self-evident:
>
> function foo(): int { return 42; }
> function wrapped_foo(): int { return foo(); }
>
> But foo() could later be changed to this:
>
> function foo(): string { return 'The Answer'; }
>
> The wrapped_foo() typehint is now broken. That's not really any different
> from foo() starting off as void/returns-null and adding a return value.
>
> In both cases, a static analyser could detect the discrepancy, but the
> Zend Engine will not, until the function is executed.
>
>
> It's a shame there's no "tail call this other function and discard its
>> result" construct.
>>
>
> Yeah, I guess what you really want is for a void function to be able to
> "goto foo();"
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 tried accessing what was supposed to be
'nothing' ($b), and got NULL with an E_NOTICE being thrown.
function myFunc() : void { ... }
$a = myFunc();
I see no reason why this should silently assign NULL to $a,
*specially* with "return null;" being explicitly forbidden. ... The
behaviour should be consistent (NULL should be accessed, as for all
undefined things), with an E_NOTICE.
I don't know how easy this would be to implement, but I agree that this
would make the "void" keyword feel more meaningful.
Does the Engine have a way to know whether a return value is being used
or discarded for optimisation purposes? If so, could that logic be
hooked to provide the Notice?
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 this truly is the case, then all you get over hinting void as the return type instead of null is a fatal error for return null; Sure you can argue for capturing intent but realistically the difference in intent between 'returns no value' and 'does not return a value' is something for philosophers to argue over not programmers. ;)
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 to pop up for existing code, assuming we applied this to built-in PHP functions. I'm not sure. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 wonder if it might cause a lot of E_NOTICEs to pop up for existing code, assuming we applied this to built-in PHP functions. I'm not sure. The way Pedro described it, it wouldn't apply to any existing functions because they wouldn't be declared void. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
>
> 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 he's writing should not return something.
IMHO, it's far more important to warn "Hey, this function returns NOTHING,
don't try to use its value because it doesn't exist!" then it is to warn
"Hey, this function can't return anything, stop trying to return things!".
Throwing an E_NOTICE when accessing a void return value would make perfect
sense, as the compiler would strict check that the function author defined
a no-return and indeed returned nothing and would also warn whoever was
calling the function that it doesn't return anything.
> We could do this, but I do wonder if it might cause a lot of E_NOTICEs to
pop up for existing code, assuming we applied this to built-in PHP
functions.
My proposal is to only throw an E_NOTICE when accessing a return value from
a function that is explicitly marked with "void". A function with no return
("return ;") but with no ": void" on the signature would not necessarily
throw an E_NOTICE.
function myFunc() { return ; }
$a = myFunc(); //NULL should be assigned to $a silently, like it is today.
function myOtherFunc() : void { return ; }
$b = myOtherFunc(); //NULL should be assigned to $b, but an E_NOTICE is
thrown.
2015-10-15 13:34 GMT-03:00 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 to
> pop up for existing code, assuming we applied this to built-in PHP
> functions.
>
> I'm not sure.
>
> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 change lands. I'd kinda like it, but it's not solving a massive problem for me. * There aren't any compelling reasons against this. The only reason given of any note that I've seen is: "There are no compelling reasons in favor of it." And I'll agree with that. Like I just said, it's not solving any major problems, and it's not going to cause any major problems. It's just a tiny, vanishingly insignificant piece of syntactic sugar which disappears before we even get to the AST. So again, could scarcely care less, so don't expect me to champion either side, but you asked "why", so here it is: It makes code reviews marginally less ugly. That's it. It's a tiny problem to solve, and likely saves less than 100ms during diff reviews, but it's a solution to a problem. Yes, it's a problem which countless developers live with to no significant negative consequence. Solo developers and small shops won't care about this since they tend to not bother with code reviews. FB has enough engineers working on its very large codebase though, that nobody has it all paged in, so code reviews are mandatory, and if we can spend five minutes of effort to loosen the parser rules in exchange for saving 1/10th of a second on every diff review that extends/shrinks a function call/signature with no overhead, then of course we would. That's a fair exchange. Apologies if you were hoping for a compelling reason. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 things first: * I don't really care if this change lands. I'd kinda like it, but it's not solving a massive problem for me. * There aren't any compelling reasons against this. The only reason given of any note that I've seen is: "There are no compelling reasons in favor of it." And I'll agree with that. Like I just said, it's not solving any major problems, and it's not going to cause any major problems. It's just a tiny, vanishingly insignificant piece of syntactic sugar which disappears before we even get to the AST. So again, could scarcely care less, so don't expect me to champion either side, but you asked "why", so here it is: It makes code reviews marginally less ugly. That's it. It's a tiny problem to solve, and likely saves less than 100ms during diff reviews, but it's a solution to a problem. Yes, it's a problem which countless developers live with to no significant negative consequence. Solo developers and small shops won't care about this since they tend to not bother with code reviews. FB has enough engineers working on its very large codebase though, that nobody has it all paged in, so code reviews are mandatory, and if we can spend five minutes of effort to loosen the parser rules in exchange for saving 1/10th of a second on every diff review that extends/shrinks a function call/signature with no overhead, then of course we would. That's a fair exchange. Apologies if you were hoping for a compelling reason. -Sara No, I think this is a good answer and part of the motivation you state could in my eyes land in the RFC. I mean there are big organizations using PHP ;-) The feature itself is free to use and misusing it shouldn't be a reason against it. //Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 answer, but I need to state a couple things first:
> * I don't really care if this change lands. I'd kinda like it, but
> it's not solving a massive problem for me.
> * There aren't any compelling reasons against this. The only reason
> given of any note that I've seen is: "There are no compelling reasons
> in favor of it." And I'll agree with that. Like I just said, it's
> not solving any major problems, and it's not going to cause any major
> problems. It's just a tiny, vanishingly insignificant piece of
> syntactic sugar which disappears before we even get to the AST.
>
> So again, could scarcely care less, so don't expect me to champion
> either side, but you asked "why", so here it is: It makes code reviews
> marginally less ugly.
>
> That's it. It's a tiny problem to solve, and likely saves less than
> 100ms during diff reviews, but it's a solution to a problem.
>
> Yes, it's a problem which countless developers live with to no
> significant negative consequence. Solo developers and small shops
> won't care about this since they tend to not bother with code reviews.
> FB has enough engineers working on its very large codebase though,
> that nobody has it all paged in, so code reviews are mandatory, and if
> we can spend five minutes of effort to loosen the parser rules in
> exchange for saving 1/10th of a second on every diff review that
> extends/shrinks a function call/signature with no overhead, then of
> course we would. That's a fair exchange.
>
> Apologies if you were hoping for a compelling reason.
>
> 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
implement trailing am I right?
function foo(
$bar
,$baz
,$boo
) { ... }
too_many_args(
$this->id
,'some constant string'
, 123
);
Wouldn't this give the same benefit as trailing commas when it comes to
adding removing arguments - a single line diff?
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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?) happens, I originally introduced this on 14th February, and it's now 14th October, so it's been exactly 8 months! Thanks! I have been waiting for this RFC to reopen. Actually wondered why void wasn't among the reserved words in the https://wiki.php.net/rfc/reserve_even_more_types_in_php_7. Regards //Björn Hm... Just noticed that HACK allows void as return type. Wonder how it works and motivation for having it? Mention in RFC? //Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
> 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 standard or clean reading.
If someone chooses to lose their precious time implementing this, it would
actually give some people a new feature (clean diffs while keeping PSR2
compliance) without taking anything away from people who oppose this. This
is not objectively bad, it just adds an option to the pool, which I think
is good.
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.
But again, I have no vote.
2015-10-15 16:16 GMT-03:00 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 answer, but I need to state a couple things first:
> > * I don't really care if this change lands. I'd kinda like it, but
> > it's not solving a massive problem for me.
> > * There aren't any compelling reasons against this. The only reason
> > given of any note that I've seen is: "There are no compelling reasons
> > in favor of it." And I'll agree with that. Like I just said, it's
> > not solving any major problems, and it's not going to cause any major
> > problems. It's just a tiny, vanishingly insignificant piece of
> > syntactic sugar which disappears before we even get to the AST.
> >
> > So again, could scarcely care less, so don't expect me to champion
> > either side, but you asked "why", so here it is: It makes code reviews
> > marginally less ugly.
> >
> > That's it. It's a tiny problem to solve, and likely saves less than
> > 100ms during diff reviews, but it's a solution to a problem.
> >
> > Yes, it's a problem which countless developers live with to no
> > significant negative consequence. Solo developers and small shops
> > won't care about this since they tend to not bother with code reviews.
> > FB has enough engineers working on its very large codebase though,
> > that nobody has it all paged in, so code reviews are mandatory, and if
> > we can spend five minutes of effort to loosen the parser rules in
> > exchange for saving 1/10th of a second on every diff review that
> > extends/shrinks a function call/signature with no overhead, then of
> > course we would. That's a fair exchange.
> >
> > Apologies if you were hoping for a compelling reason.
> >
> > 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
> implement trailing am I right?
>
> function foo(
>$bar
> ,$baz
> ,$boo
> ) { ... }
>
> too_many_args(
>$this->id
> ,'some constant string'
> , 123
> );
>
> Wouldn't this give the same benefit as trailing commas when it comes to
> adding removing arguments - a single line diff?
>
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 E_NOTICE. We could do this, but I do wonder if it might cause a lot of E_NOTICEs to pop up for existing code, assuming we applied this to built-in PHP functions. I'm not sure. The way Pedro described it, it wouldn't apply to any existing functions because they wouldn't be declared void. 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. Why shouldn't it? For the scalar types, internal and userland functions behave almost the same. I'd like there the two to converge, not diverge. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 implementation is two lines. The rest is a bunch of unit tests for positive and negative results. We've spent FAR more time discussing it than implementing it took. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 implement > trailing am I right? > > Wouldn't this give the same benefit as trailing commas when it comes to > adding removing arguments - a single line diff? > IMO, that would solve the one small problem in exchange for a new small problem. That of the cognitive overhead of parsing leading commas where standard practice calls for trailing commas. And before you counter than the final optional comma also comes with overhead, let me point out that the array consistency argument. We have trailing commas there already, so no new mental overhead. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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. > Leading commas would break away from PSRs and one should not have to choose > between a standard or clean reading. > > If someone chooses to lose their precious time implementing this, it would > actually give some people a new feature (clean diffs while keeping PSR2 > compliance) without taking anything away from people who oppose this. This > is not objectively bad, it just adds an option to the pool, which I think > is good. > > 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. > > But again, I have no vote. > > I want to clarify, I have no objection to this - was just asking if making the decision that way back then at FB would have merited the same result. I'm in your boat, whether its added or not does not matter to me.
Re: [PHP-DEV] [RFC] Arrow Functions
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 here. Here's a small example: $y = 10; $result = array_map(function($x) => $x + $y, [1, 2, 3]); // $result is [11, 12, 13] Thanks for people who have participated in conversation so far, as well as those who participated in Bob's short closures proposal as well. [1]: https://wiki.php.net/rfc/arrow_functions Well my comments are: - By having => as operator we block future idea to remove function keyword in case limitation in parser is overcome. - Also suppose one would like to do a simple grep for all anonymous function in a project, having same as array key will require regexp search. - It would also be good is this RFC includes all required text instead referring to Bob's old one. - I also misses if default values are supported. - Not being able to overcome limitation is parser, seems like this RFC is a compromise for some developers... - For me as a userland developer I prefer Bob's old proposal but with added type hints, default values and requiring parenthesis for the single parameter case. r//Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 that a > coding > > standard for the organization, you would not have needed to implement > > trailing am I right? > > > > Wouldn't this give the same benefit as trailing commas when it comes to > > adding removing arguments - a single line diff? > > > IMO, that would solve the one small problem in exchange for a new > small problem. That of the cognitive overhead of parsing leading > commas where standard practice calls for trailing commas. > > And before you counter than the final optional comma also comes with > overhead, let me point out that the array consistency argument. We > have trailing commas there already, so no new mental overhead. > > Wasn't planning on countering, just trying to show that Hack made a conscious choice to go this way. I personally don't see a benefit, as its not hard to read a diff that has a new comma on a previous line following by a new var/value on the next - but if people do then by all means add it in :) 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 correct?
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 correct? > Excellent question. The patch on Sammy's RFC was written in Feb 2013, before variadics, so it doesn't take them into account. 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. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 assuming a > > function call/definition may only have one or the other, is that correct? > > > Excellent question. The patch on Sammy's RFC was written in Feb 2013, > before variadics, so it doesn't take them into account. > > 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 allow multiple splats in one call. Something like this (after trailing comma patch) should be just fine: foo( ...$args, ...$moreArgs, ...$evenMoreArgs, ); We don't allow multiple variadic parameters. However I also see little point in explicitly forbidding this one case. You'd be able to use the trailing comma in all cases ... apart from that one single instance. Nikita
Re: [PHP-DEV] PHP 7.0.0RC5 is available
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 effective way - by investing even more into stronger testing and verification of the critical points. Stability matters more than ever. We're on the finishing straight, hold on tight! I just wanted to check the Changelog, but it hasn't changed since RC3: http://www.php.net/ChangeLog-7.php Inside the archive it's in the NEWS file, but it would be nice if the ChangeLog page would be in sync. Maybe someone can do that quickly? Thanks for this awesome PHP 7, I'm currently testing it with some bigger projects, migrating them, doing performance checks, it's a lot of fun seeing this incredible performance improvement and memory reduction! Thanks to all contributors! Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)
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 explaining why I chose this name. It doesn't really say anything I haven't said already, it just summarises it. In particular, it lists a bunch of languages using `void`, some of which do what PHP does. The new section is here: https://wiki.php.net/rfc/void_return_type#why_call_it_void_and_not_null Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 seems to be some extra fatal errors, for a developer there seems little value. From a user confusion point of view; PHP currently considers return; and return null; to be equivalent (in fact some code style checkers will replace one with the other) If (and only if) a function has a return type of void these two statements are no longer equivalent - one is a fatal error one is not. For any other return type specification, return null; and return; would behave the same. This in itself would be enough for me to be against adding a return type of void. This is true, but `void` isn't an ordinary return type. It exists to ensure a function doesn't return anything, unlike other return types which exist to ensure a function returns a specific thing. `return null;` is *technically* equivalent to `return;`, but it's not quite the same in intent, usually. We could special-case it and allow it, but why? The return value isn't supposed to be used, why should we allow you to specify it? A void function in PHP does technically produce a result of null, but it might as well be false or -1 or whatever for all we care. Also, if `return null;` is to work, should `return(null);` also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It seems silly to me since, again, the return value is insigificant. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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. > >Why shouldn't it? For the scalar types, internal and userland functions behave >almost the same. Just for the same reason that an existing function that uses bare "return;" won't automatically be considered "void" - nobody has explicitly decided that that's the intent. Sure, internal functions whose value shouldn't be used *could* be marked void, and those would start raising Notices if that was part of void's behaviour. But there would only be a blizzard of Notices if someone bulk updated every function in core which happens to return null, which doesn't seem like an automatic part of creating a void return behaviour. Especially if the whole point is that "void" signifies something more than "always returns null". Since it's been mentioned a couple of times, I'd like to say that although the documentation is official, I think it should be considered descriptive not prescriptive - if it labels something as void, but the Engine doesn't consider it so, the manual would be wrong, not the Engine. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 void > >would > >> suddenly be annotated in the Engine as such and start returning > >notices. > > > >Why shouldn't it? For the scalar types, internal and userland functions > behave almost the same. > > Just for the same reason that an existing function that uses bare > "return;" won't automatically be considered "void" - nobody has explicitly > decided that that's the intent. > > Sure, internal functions whose value shouldn't be used *could* be marked > void, and those would start raising Notices if that was part of void's > behaviour. But there would only be a blizzard of Notices if someone bulk > updated every function in core which happens to return null, which doesn't > seem like an automatic part of creating a void return behaviour. > Especially if the whole point is that "void" signifies something more than > "always returns null". > > Since it's been mentioned a couple of times, I'd like to say that although > the documentation is official, I think it should be considered descriptive > not prescriptive - if it labels something as void, but the Engine doesn't > consider it so, the manual would be wrong, not the Engine. > Could we change the documentation for existing functions to return null, and start using void properly moving forward? Thanks, Korvin
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 allow multiple splats in one call. Something like this (after trailing > comma patch) should be just fine: > > foo( > ...$args, > ...$moreArgs, > ...$evenMoreArgs, > ); > > We don't allow multiple variadic parameters. However I also see little point > in explicitly forbidding this one case. You'd be able to use the trailing > comma in all cases ... apart from that one single instance. > Derp, right. Sorry. I don't really know PHP. Is it like Ruby? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
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 should we change the documentation anyway? We've used void for a very long time, at least 17 years[0]. We don't just use it in the PHP manual, it's also used in docblocks and the PHP source code's function prototypes. It's the commonly-accepted, widely-used term. Until now this was uncontroversial. Why should we move heaven and earth when there's nothing wrong? [0] https://web.archive.org/web/19991002011107/http://php.net/manual/function.sort.php3 -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments
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 Powers > sammyk.me Sammy, I think this proposal is too narrow. If we are going to bother to change the language, then let's do it consistently and allow trailing commas on all lists in the grammar. These are the ones on mind right now: - use declarations - group use declarations - function call argument list - class member lists (both constants and properties) - argument list declarations - arrays (already allowed) As exemplified in this gist: https://gist.github.com/marcioAlmada/75f8f1d47da5dcac2e57 Why? Because it prevents a reality where each PHP minor version introduces trailing commas in a new different place, hurting code portability. Because it couldn't get more consistent. And more importantly: because we would get rid of this discussion about trailing commas, forever j/k :) ty, Márcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?
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 good thing, but they aren't the same nor accomplish the same thing. I hope what I said made sense. Well, you've successfully convinced me that PHP needs both multi-threading and async IO. I hope you're happy now... --Larry Garfield Quite happy. Sorry about that... :) -- Stephen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
