Re: [PHP-DEV] Make `always true` SPL methods return void

2020-06-18 Thread Jesse Rushlow
* Disclaimer - I have not thoroughly reviewed the bug report or PR mentioned. >From a PHP developers perspective, if I was calling a method that returned true. I would automatically assume that the method is capable of returning the inverse of that as well. I see Dan's point of "let sleeping dogs

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Benas IML
Hey Andreas, > Another example would be the "public" access specifier, which can be omitted and the method will still be public. > > There is a major difference though: > > If you look at a method without "public", or a parameter without "mixed", there is a chance that the developer actually

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Larry Garfield
On Thu, Jun 18, 2020, at 3:49 PM, Andreas Hennings wrote: > On the other hand, for a constructor the ": void" is just stating the > obvious. > Even if you see a constructor without ": void", you still know that this is > not meant to return anything. > Either because it is generally agreed to be

[PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

2020-06-18 Thread Ilija Tovilo
Hi Björn >> I'd like to announce the match expression v2 RFC: >> https://wiki.php.net/rfc/match_expression_v2 > Well one could argue that when working with legacy code containing > switch statements where one gradually migrates to match, it might be > easier to have the same separator, i.e. ":".

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Andreas Hennings
On Thu, 18 Jun 2020 at 22:29, Benas IML wrote: > Hey Andreas, > > It seems that you actually haven't read my reply carefully enough. > > > But this distinction would only apply in PHP 8. And the only difference > here > is whether returning a value is just deprecated or fully illegal. > > In PHP

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Benas IML
Hey Andreas, It seems that you actually haven't read my reply carefully enough. > But this distinction would only apply in PHP 8. And the only difference here is whether returning a value is just deprecated or fully illegal. > In PHP 9, constructors with ": void" would be the same as without ":

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Andreas Hennings
On Thu, 18 Jun 2020 at 18:33, Benas IML wrote: > Hey Andreas, > > That is incorrect. Adding an explicit `: void` does change behavior since > only then the check (whether something is being returned) is enforced. This > allows PHP 8 projects to take advantage of this enforcement while being >

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

2020-06-18 Thread Arvids Godjuks
Hello everyone, I would like everyone to slow down a bit and give a think about this: English is not the primary language for the vast majority of people. are a thing and a lot of people, actually, work with PHP that either does not know English at all or, know the basics and rarely have the

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

2020-06-18 Thread Bob Weinand
> Am 18.06.2020 um 20:24 schrieb Lynn : > > > > On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand > wrote: > P.s. And to be honest, I've never heard from a dark-skinned person that they > felt actually oppressed by words like blacklist. > > And here my personal opinion,

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

2020-06-18 Thread Lynn
On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand wrote: > P.s. And to be honest, I've never heard from a dark-skinned person that > they felt actually oppressed by words like blacklist. > > And here my personal opinion, to be taken with a grain of salt: This whole > white- and blacklist discussion is

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Benas IML
Hey Bob, Your examples (regarding constructors/destructors) do make sense since you are using these methods for what they should be used: initialization and freeing resources. But, this is off-topic to the RFC. This RFC only proposes to enforce no-return rule on constructors/destructors. And

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Benas IML
Hey Alexandru, Your email was marked as spam for me, thus this is a late response, sorry about that! Nikita analyzed top 2,000 Composer packages and found that 95 of them will have a BC break. As a solution, to minimize the amount of BC breaks, I'm proposing to have a deprecation warning in PHP

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Bob Weinand
Hey, > Am 18.06.2020 um 17:18 schrieb Benas IML : > > Hey Bob, > > Magic methods are **never** supposed to be called directly (even more if that > method is a constructor or a destructor). If that's not the case, it's just > plain bad code. But by enforcing these rules, we make sure that less

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Benas IML
Hey Andreas, That is incorrect. Adding an explicit `: void` does change behavior since only then the check (whether something is being returned) is enforced. This allows PHP 8 projects to take advantage of this enforcement while being respective to older codebases. And well, the explicit `:

[PHP-DEV] VCS Account Request: ilutov

2020-06-18 Thread Ilija Tovilo
Contribute to PHP :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Andreas Hennings
Hi The RFC introduces what I call a "meaningless choice", by making something possible that is currently illegal, but which does not change behavior. https://3v4l.org/daeEm It forces organisations, frameworks or the php-fig group to introduce yet another coding convention to decide whether or

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Benas IML
Hey Bob, Magic methods are **never** supposed to be called directly (even more if that method is a constructor or a destructor). If that's not the case, it's just plain bad code. But by enforcing these rules, we make sure that less of that (bad code) is written and as a result, we make PHP code

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

2020-06-18 Thread Sara Golemon
On Wed, Jun 17, 2020 at 7:23 PM Ben Ramsey wrote: > I don’t understand this question: > > > Are you okay with re-voting on the attribute syntax for PHP 8.0? > > I recommended this as a front-line question so as to remove any hint of impropriety about the vote. For example, where the first round

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

2020-06-18 Thread Theodore Brown
On Thu, June 18, 2020 at 7:40 AM Aleksander Machniak wrote: > If @@ wins, will a sequence of 3-or-more @ characters forbidden? > It is not stated in the RFC. I.e. what happens if you write: > > @@@ExampleAttribute() > class Foo > { > } > > @@@some_function(); Hi Aleksander,

Re: [PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax

2020-06-18 Thread Theodore Brown
On Thu, June 18, 2020 at 8:40 AM Mark Randall wrote: > On 18/06/2020 00:59, Theodore Brown wrote: > > I've opened voting on the Shorter Attribute Syntax RFC: > > https://wiki.php.net/rfc/shorter_attribute_syntax > > I'd be wary of @@ simply because if we do add validation to them, > we would

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

2020-06-18 Thread Derick Rethans
On Wed, 17 Jun 2020, Ben Ramsey wrote: > > On Jun 17, 2020, at 18:59, Theodore Brown wrote: > > > > I've opened voting on the Shorter Attribute Syntax RFC: > > https://wiki.php.net/rfc/shorter_attribute_syntax > > > > Since all RFCs require a primary vote with a 2/3 majority, there is > > a

[PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax

2020-06-18 Thread Mark Randall
On 18/06/2020 00:59, Theodore Brown wrote: I've opened voting on the Shorter Attribute Syntax RFC: https://wiki.php.net/rfc/shorter_attribute_syntax I'd be wary of @@ simply because if we do add validation to them, we would likely want to use the suppression operator to indicate that a class

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

2020-06-18 Thread Bob Weinand
> Am 18.06.2020 um 00:36 schrieb Jakob Givoni : > To repeat what has been said many times over now: It's when "black" is > associated with "bad" in a composite term like "blacklist" we should > consider being considerate of a group of people who actually have skin > of that color. > > Best, >

[PHP-DEV] Re: VCS Account Request: ilutov

2020-06-18 Thread PHP Group
VCS Account Approved: ilutov approved by cmb \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Bob Weinand
> Am 17.06.2020 um 01:10 schrieb Benas IML : > > Hey internals, > > This is a completely refined, follow-up RFC to my original RFC. Based on the > feedback I have received, this PR implements full validation and implicitly > enforces `void` rules on constructors/destructors while also allowing

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

2020-06-18 Thread Aleksander Machniak
On 18.06.2020 01:59, Theodore Brown wrote: > Hi internals, > > I've opened voting on the Shorter Attribute Syntax RFC: > https://wiki.php.net/rfc/shorter_attribute_syntax If @@ wins, will a sequence of 3-or-more @ characters forbidden? It is not stated in the RFC. I.e. what happens if you write:

[PHP-DEV] Re: VCS Account Request: theodorejb

2020-06-18 Thread PHP Group
VCS Account Approved: theodorejb approved by derick \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] VCS Account Request: theodorejb

2020-06-18 Thread Theodore Brown
I would like the ability to vote on PHP RFCs. I worked on two successful RFCs for PHP 7.4 (numeric literal separators and the curly brace array/string access deprecation), and have also contributed other bug fixes and improvements to core. -- PHP Internals - PHP Runtime Development Mailing

[PHP-DEV] Re: [RFC] [DISCUSSION] Make constructors and destructors return void

2020-06-18 Thread Benas IML
Hey internals, 1. Since there is confusion around multiple RFCs, I would like to emphasize that this RFC (Make constructors and destructors return void) superseded the original RFC (Allow void return type on constructors/destructors). Thus, the latter RFC is now abandoned. Link to the new RFC:

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

2020-06-18 Thread Jakob Givoni
On Thu, Jun 18, 2020 at 9:39 AM Nikita Popov wrote: > >> In a mail that probably went to everyone's spam folder, I asked for >> opinions on allowing use of .\Foo as an alternative to Foo in the >> current namespace, thus reducing friction with reserved keywords even >> more. Any thoughts on that

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

2020-06-18 Thread Nikita Popov
On Thu, Jun 18, 2020 at 8:44 AM Claude Pache wrote: > Hi, > > The following part of the proposal is problematic: Allow keywords in > definition of classes, functions, const, etc. > > class KEYWORD {}interface KEYWORD {}trait KEYWORD {}function KEYWORD() > {}const KEYWORD = 0;use Foo as KEYWORD;

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

2020-06-18 Thread Nikita Popov
On Thu, Jun 18, 2020 at 12:06 AM Jakob Givoni wrote: > On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov > wrote: > > > > Hi internals, > > > > Inspired by the recent discussion on reserved keyword reservation, I'd > like > > to propose the following RFC: > > > >

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

2020-06-18 Thread Marcio Almada
Hi, What other language allows this? None that I can think of. Do we want PHP > doing something it's most closely related languages do not allow? Why > don't they allow this? Most language implementations don't do that because we are all using parser generators to do the heavy lifting of

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

2020-06-18 Thread Claude Pache
Hi, The following part of the proposal is problematic: Allow keywords in definition of classes, functions, const, etc. class KEYWORD {} interface KEYWORD {} trait KEYWORD {} function KEYWORD() {} const KEYWORD = 0; use Foo as KEYWORD; Under your proposal, the following code will compile without