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
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 rank
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 more
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 ran
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 thro
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. Addition
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 nam
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 list
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 https://wiki.php.net/rfc/change-terminology-to-ex
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 expre
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. Othe
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
> chang
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 'cl
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 r
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 b
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 allowlist
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 wit
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, vi
>
> 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 enforc
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 is
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 constructors/destruc
30 matches
Mail list logo
