On Thu, Jun 18, 2020 at 1:59 AM Theodore Brown
wrote:
> Hi internals,
>
> 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 main vote to approve the secondary
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? What problems are we creating by allowing this? I
can imagine this would make autoloading functions and constants by
namespace
On Wed, June 17, 2020 at 7:23 PM 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
> On Jun 17, 2020, at 18:59, Theodore Brown wrote:
>
> Hi internals,
>
> 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 main vote to approve the secondary
Hi internals,
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 main vote to approve the secondary ranked-choice vote.
For the ranked-choice poll, fill in your first
On Wed, Jun 17, 2020 at 4:22 PM Chase Peeler wrote:
>
> Please stop using the term "glob." As a person that is above what many
> would consider an ideal weight, I've been called a "useless glob" on
> multiple occasions. This term is harmful to me as a result.
>
Though I know you're joking (and I
Just a heads up :)
Both PR and the RFC were updated to reflect the changes and to minimize the
amount of BC breaks.
TL;DR the RFC proposes to deprecate returning non-void values from
constructors/destructors in PHP 8.0 and always enforce void rules on
constructors/destructors in PHP 9.0.
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:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced
On Mon, Jun 15, 2020 at 6:49 PM Michael Cordover wrote:
>
> The black in black hole and the white in whitespace are descriptions of the
> actual colors of these things.
> There's no value judgement there.
> Blacklist, on the other hand, is explicitly making a judgement that things on
> that
Den 2020-06-16 kl. 14:14, skrev Michał Brzuchalski:
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
The RFC is here
Den 2020-06-16 kl. 18:17, skrev Ilija Tovilo:
Hi Björn
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2
I do like this RFC and have one comment. Would it be suitable
to have : as a separator instead of =>?
`=>` is usually used in combination
On Wed, Jun 17, 2020 at 10:22:02AM -0400, Chase Peeler wrote:
> None of the above are actually true (except for the fact that I'm
> overweight). The point I'm trying to raise is that context matters, and
> changing terms because some people refuse to understand the context is not
> justified.
On Wed, Jun 17, 2020 at 5:46 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> Hi Lester,
>
> wt., 16 cze 2020 o 15:55 Lester Caine napisał(a):
>
> > On 16/06/2020 13:14, Michał Brzuchalski wrote:
> > > I'd like to start a discussion period for my RFC which proposes to
>
On 17.06.2020 at 15:36, Christian Schneider wrote:
> I'm not sure I understand the second part "and doesn't have an explicit `:
> void` declaration".
> If there is a ' : void' declaration then returning any value will be an error.
> As far as I can see this is already the case:
> php -r
Hey Christian,
Wrong wording, sorry! :)
> But I definitely wouldn't want a deprecation warning for constructors without
> explicit ': void' as I see no reason to force people to use it.
This RFC proposes 2 things:
1) If a non-void value is returned from a constructor/destructor, a
deprecation
Am 17.06.2020 um 13:59 schrieb Benas IML :
> We should allow newer codebases to enforce `void` rules on
> constructors/destructors by allowing to explicitly declare return type as
> `void`.
I don't see a big benefit in this explicit return type void as newer codebases
hopefully will try to get
Thanks everybody for the replies.
> However, I am also fine if the void return value is only enforced when the
> void return
> type is declared. Additionally, we could emit a deprecation notice/warning
> when
> there is no return type declaration, but a value is returned. I think this
> would
On Wed, 17 Jun 2020 at 03:00, Gabriel Caruso wrote:
>
> so changing it to `void` and
> just invoke these methods sounds reasonable to me.
What's the benefit of doing the change?
There will almost certainly be some code somewhere that would be
broken by changing it, so it needs some benefit for
On 17.06.2020 at 11:35, Dan Ackroyd wrote:
> On Tue, 16 Jun 2020 at 01:35, Benas IML wrote:
>>
>> Hey internals,
>>
>> RFC: https://wiki.php.net/rfc/constructor_return_type
>>
>
> Hi Benas,
>
> Instead of deleting RFC docs, please can you update their status to
> 'inactive' or 'replaced by xyz'.
On Wed, Jun 17, 2020 at 11:46:12AM +0200, Michał Marcin Brzuchalski wrote:
> Therefore IMO we should choose a new name wisely so it can be
> self-descriptive.
Also: important to choose words/names that are being adopted elsewhere; thus
people will recognise it as they have learned it elsewhere.
Hi Kalle,
wt., 16 cze 2020 o 14:35 Kalle Sommer Nielsen napisał(a):
> ...
> > The RFC is here
> https://wiki.php.net/rfc/change-terminology-to-excludelist
>
> The pull request in the linked RFC does not seem to reflect all the
> details of this RFC, the PR also changes the whitelist to
Hi Lester,
wt., 16 cze 2020 o 15:55 Lester Caine napisał(a):
> On 16/06/2020 13:14, Michał Brzuchalski wrote:
> > I'd like to start a discussion period for my RFC which proposes to change
> > the use of "blacklist" in Opcache configuration with better
> > self-descriptive terminology.
>
> Since
On Tue, 16 Jun 2020 at 01:35, Benas IML wrote:
>
> Hey internals,
>
> RFC: https://wiki.php.net/rfc/constructor_return_type
>
Hi Benas,
Instead of deleting RFC docs, please can you update their status to
'inactive' or 'replaced by xyz'.
The wiki is part of the history of the discussion, and
On Wed, Jun 3, 2020 at 3:15 PM Nikita Popov wrote:
> Hi internals,
>
> I've opened voting on the stable sorting RFC:
> https://wiki.php.net/rfc/stable_sorting
>
> Voting closes 2020-06-17.
>
This RFC has been accepted unanimously, with 45 votes in favor.
Regards,
Nikita
On Wed, Jun 3, 2020 at 11:11 PM Gabriel Caruso
wrote:
> On Wed, 3 Jun 2020 at 12:32, Nikita Popov wrote:
>
>> On Sun, May 31, 2020 at 11:20 PM Gabriel Caruso <
>> carusogabrie...@gmail.com> wrote:
>>
>>> On Sun, 31 May 2020 at 15:57, Nikita Popov wrote:
>>>
On Fri, May 29, 2020 at 6:45 PM
Hi internals
> I'd like to announce the match expression v2 RFC:
> https://wiki.php.net/rfc/match_expression_v2
Last reminder: I'm opening the vote on Friday. The vote is going to be
a straightforward yes/no vote.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
>
> This PR should also address all of Máté's concerns since it makes
> constructors and destructors always return `void` (even when no explicit
> `void` return type is specified).
To be clear, my main concern was that declaring a void return type
shouldn't be
allowed, unless it's actually
On Wed, Jun 17, 2020 at 9:18 AM Christian Schneider
wrote:
> Am 16.06.2020 um 21:30 schrieb Benas IML :
> > I put the original RFC on hold and created a new PR [0] for implicitly
> > enforcing `void` rules on both constructors and destructors. Note, that
> > this results in a BC break since it
Am 16.06.2020 um 21:30 schrieb Benas IML :
> I put the original RFC on hold and created a new PR [0] for implicitly
> enforcing `void` rules on both constructors and destructors. Note, that
> this results in a BC break since it is no longer legal to return non-void
> value from
29 matches
Mail list logo
