On Wed, Jun 22, 2022 at 6:01 PM Nicolas Grekas
wrote:
> Hi Benjamin and Derick,
>
> I'm replying to both of you because I see some things in common in your
> comments.
>
> >
>> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
>
> I would prefer if this was an explicit
On Wed, Jun 22, 2022 at 12:47 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Hi everyone!
>
> I'd like to open a discussion on this RFC, to auto-implement Stringable for
> string-backed enums:
> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
> I'm looking
Hi Tim,
On Mon, Jan 10, 2022 at 3:06 PM Tim Düsterhus, WoltLab GmbH <
duester...@woltlab.com> wrote:
> Hi Internals!
>
> this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th.
>
> Christoph Becker granted me RFC editing permissions and I've now written
> up our proposal as a p
On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl wrote:
> Hea all.
>
> On 15.11.21 10:52, Derick Rethans wrote:
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov
> wrote:
> >>
> >>> This RFC takes the more direct route of dep
On Mon, Nov 15, 2021 at 11:26 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Hi Nikita, hi everybody,
>
> Le mer. 25 août 2021 à 12:03, Nikita Popov a écrit
> :
>
> > Hi internals,
> >
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have no
On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan
wrote:
> PS i've seen *HORRIBLE* fs performance for php-running-on-windows,
> where the same filesystem operations on the same files took like 5 seconds
> on linux-running-on-vmware-on-laptop-running-windows-10, versus several
> minutes for the s
On Fri, Jul 23, 2021 at 4:31 PM Deleu wrote:
> On Fri, Jul 23, 2021 at 2:36 PM Derick Rethans wrote:
>
> > From the RFC: «Taking all these elements into account, the preference
> > of... and thus to use the "?X&Y" syntax».
> >
> > I think this would be a mistake. You touch upon operator preceden
On Fri, Jul 23, 2021 at 12:55 PM Mark Randall wrote:
> On 23/07/2021 10:58, Nicolas Grekas wrote:
> > Hi everyone,
> > I wrote everything down about the reasons why here:
> > https://wiki.php.net/rfc/nullable_intersection_types
>
>
> IMO we should require brackets and forbid not using them when c
On Tue, Jul 6, 2021 at 12:58 PM Rowan Tommins
wrote:
> On 06/07/2021 11:31, Benjamin Eberlei wrote:
> > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
> > then calling ReflectionAttribute::getArguments would also require to
> > resolve the typ
On Tue, Jul 6, 2021 at 9:31 AM Nicolas Grekas
wrote:
> Hi NIkita,
>
> I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting
> > will close on 2021-07-14.
> >
> > Note that relative to the original RFC, new support is limited to
> parameter
> > default values, attribute argume
On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield
wrote:
> Hi folks. The vote for the Partial Function Application RFC is now open,
> and will run until 30 June.
>
> https://wiki.php.net/rfc/partial_function_application
>
> Of particular note, a few people had asked about using ...? instead of ...
On Fri, Jun 4, 2021 at 5:20 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previo
On Fri, Jun 4, 2021 at 5:20 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previo
On Sun, May 9, 2021 at 8:49 AM Joe Watkins wrote:
> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite
On Sat, Apr 24, 2021 at 2:56 PM Pierre wrote:
> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit :
> > Hello Internals,
> >
> > I'm sending this email to open discussion about sealed classes,
> > interfaces, and traits feature for PHP 8.1.
> >
> > I have create a Draft RFC here:
> > https://wiki.p
On Sat, Apr 3, 2021 at 5:30 PM Benjamin Eberlei wrote:
>
>
> On Fri, Apr 2, 2021 at 3:14 AM Aaron Piotrowski wrote:
>
>>
>> > On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals <
>> internals@lists.php.net> wrote:
>> >
>> > I do n
On Fri, Apr 2, 2021 at 3:14 AM Aaron Piotrowski wrote:
>
> > On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals <
> internals@lists.php.net> wrote:
> >
> > I do not care which name is chosen, but if we are going to have this
> > sort of thing in the language, it ought to be a bottom type, no
On Thu, Apr 1, 2021 at 3:56 PM Andreas Leathley wrote:
> On 01.04.21 10:56, Benjamin Eberlei wrote:
> > This RFC is using the declaration of the return type, to specify that it
> > never returns. As such noreturn or never is a keyword a long the lines of
> > public or f
On Tue, Mar 30, 2021 at 5:07 PM Matthew Brown
wrote:
> Hey everyone!
>
> The vote for adding noreturn is now open:
>
> https://wiki.php.net/rfc/noreturn_type
>
> Voting will run through April 13th
>
> Best wishes,
>
> Matt and Ondrej
>
I voted no, because i think this should at the maximum be an
On Sat, Mar 13, 2021 at 5:51 PM David Gebler wrote:
> With the introduction of attributes in PHP 8, this new behaviour is still
> quite sparsely documented. Some of the articles I've seen out there,
> though, liken PHP's attributes to similar constructs in other languages
> including decorators i
On Wed, Mar 10, 2021 at 10:51 PM Kalle Sommer Nielsen wrote:
> Den ons. 10. mar. 2021 kl. 20.22 skrev Dan Ackroyd >:
> >
> > Hi internals,
> >
> > Well, technically this is addressed more to people who read internals.
> >
> > Please don't contact people off list putting pressure on them to vote
This is
On Wed, Mar 3, 2021 at 4:04 PM Nikita Popov wrote:
> Hi internals,
>
> I would like to propose allowing the use of "new" inside various
> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>
> In particular, this allows specifying object default values for properties
>
On Sat, Feb 27, 2021 at 5:24 PM Kamil Tekiela wrote:
> >
> > The issue is, as said, that this only happens in an error situation.
> > Thus if users only test "does my site still work after update?" (what
> > many do ...) won't notice this, till something fails, which would have
> > been caught ni
On Thu, Feb 11, 2021 at 12:36 AM Kamil Tekiela wrote:
> Hi internals,
>
> I have started voting on https://wiki.php.net/rfc/mysqli_default_errmode
> The voting period is 2020-02-11 -- 2020-02-28
>
While the change in itself is something I want to see, I voted no on this
proposal because its a BC
On Thu, Dec 17, 2020 at 5:30 PM Aaron Piotrowski wrote:
> Hello everyone!
>
> I would like to introduce an RFC for adding full-stack fibers to PHP:
> https://wiki.php.net/rfc/fibers
>
> Fibers are primarily used to implement green-threads or coroutines for
> asynchronous I/O. Fibers are similar t
On Wed, Jan 13, 2021 at 1:34 PM Marco Pivetta wrote:
> On Sun, Jan 10, 2021 at 2:48 AM G. P. B. wrote:
>
>> Just to clarify this raises an E_DEPRECATED right?
>> Could it make sense to raise E_USER_DEPRECATED instead?
>>
>
> I hadn't checked this before, but as per George's message, this is
> wo
On Wed, Jan 13, 2021 at 1:05 PM Brent Roose wrote:
> Hi Sara
>
> > On 22 Dec 2020, at 19:54, Sara Golemon wrote:
> >
> > On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas <
> > nicolas.grekas+...@gmail.com> wrote:
> >
> >> It would be great to allow adding this attribute on classes. What about
> >
On Mon, Dec 28, 2020 at 9:22 PM Larry Garfield
wrote:
> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to offer
> you round 2 on enumerations. This is in the spirit of the previous
> discussion, but based on that discussion a great deal has been reworked
On Sat, Dec 19, 2020 at 8:27 PM Rowan Tommins
wrote:
> On 19/12/2020 11:28, Benjamin Eberlei wrote:
> > This is my take on parameter names now being public API, at its future
> > potential for code maintenance, refactoring and backwards compatibility.
> >
> &g
Hi internals,
another RFC using attributes for 8.1. The patch itself for this is really
small, but the implications require a detailed discussion and scrutiny.
This is my take on parameter names now being public API, at its future
potential for code maintenance, refactoring and backwards compatib
Hi internals,
I have updated the RFC for a #[Deprecated] attribute that wasn't completed
for PHP 8.0 due to time constraints and I am able to restart the discussion
now.
https://wiki.php.net/rfc/deprecated_attribute
The following updates have been made:
- focus on only method and function depre
Hi Máté
we talked about this before and I think it's a good addition. Two
suggestions to improve the RFC:
The RFC could include more details on how the behavior works exactly in
combination with long running I/O. Lets say the default socket timeout
being 60 seconds, andt the max execution wall ti
On Wed, Oct 14, 2020 at 1:56 AM tyson andre
wrote:
> Hi internals,
>
> > As far as php.net can help with PHP's reputation, I think a brief
> homepage
> > intro that showcased some modern-looking PHP code would be great (e.g.
> > typescriptlang.org, golang.org). The docs design could also be
> > s
Hi Roman,
On Mon, Oct 12, 2020 at 9:57 AM Roman Pronskiy
wrote:
> Hello Internals,
>
> The PHP 8 release is going to be huge, and in some sense, you could
> say it's a whole new language. There is a feeling that more can be
> done to promote it more extensively.
>
> Usually for releases, there’s
On Tue, Oct 6, 2020 at 6:21 PM Andreas Leathley wrote:
> On 06.10.20 17:15, Sara Golemon wrote:
> > My opinion on constructor property promotion (CPP) is that it's something
> > for small value object classes and should probably be regarded as
> > code-smell on larger classes. At the same time, a
On Tue, Sep 29, 2020 at 3:45 PM Larry Garfield
wrote:
> On Mon, Sep 28, 2020, at 12:06 PM, Benjamin Eberlei wrote:
> > On Mon, Sep 28, 2020 at 4:35 PM Benjamin Morel >
> > wrote:
> >
> > > On Mon, 28 Sep 2020 at 15:17, Nicolas Grekas <
> nicolas.grekas+...
On Mon, Sep 28, 2020 at 2:58 PM Nicolas Grekas
wrote:
>
> Hi Benjamin, hi everyone
>>>
>>> I'm wondering if the syntax that allows for several attributes is really
>>> future-proof when considering nested attributes:
>>>
>>>
>>> *1.*
>>> #[foo]
>>> #[bar]
>>>
>>> VS
>>>
>>>
>>> *2.*
>>> #[foo, ba
On Mon, Sep 28, 2020 at 4:35 PM Benjamin Morel
wrote:
> On Mon, 28 Sep 2020 at 15:17, Nicolas Grekas
> wrote:
>
>> I assume the 80% case is properties, because attributes did not have
>>> docblock annotations yet, that means this use-case isn't even possible at
>>> the moment. Yet annotations on
On Mon, Sep 28, 2020 at 2:25 PM Benjamin Morel
wrote:
> On Mon, 28 Sep 2020 at 13:56, Benjamin Eberlei
> wrote:
>
>
>> imho, we should pick the 80% use-case and advise to desugar the code if
>> other behavior is desired. For me the 80% case is that the attribut
On Mon, Sep 28, 2020 at 12:36 PM Nikita Popov wrote:
> Hi internals,
>
> When the constructor property promotion landed, the question of how it
> interacts with attributes on promoted properties did not get fully
> resolved. See https://wiki.php.net/rfc/constructor_promotion#attributes
> for what
On Sun, Sep 27, 2020 at 10:23 AM Nicolas Grekas
wrote:
> Hi Benjamin, hi everyone
>
> I'm wondering if the syntax that allows for several attributes is really
> future-proof when considering nested attributes:
>
I feel this question is what an RFC for nested attributes has to weigh. We
have esta
On Tue, Sep 15, 2020 at 8:20 AM Brent Roose wrote:
> Hey Dmitiry
>
> Speaking of the JIT. I remember berblei mentioning that the JIT
> configuration options were going to change prior to the final 8 release (
> https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applicatio
On Sat, Sep 12, 2020 at 10:23 PM Olle Härstedt
wrote:
> Hi internals!
>
> Separation of data and behaviour is both a fun and hard discussion,
> especially considering:
>
> * "It should be possible to add new features without touching old code";
> and
> * "Principle of Least Privilege" (never expo
On Fri, Aug 21, 2020 at 4:19 PM Volker Theile <
volker.the...@openmediavault.org> wrote:
> Hi all,
>
> i've opened the tracker issue https://bugs.php.net/bug.php?id=80004
> which requests Linux PAM (pluggable authentication modules) support in
> PHP8. IMO PAM is an essential feature that is requir
On Fri, Aug 21, 2020 at 3:36 PM Paul M. Jones wrote:
> Hi all,
>
> On Aug 21, 2020, at 08:23, Benjamin Eberlei wrote:
>
> It was stopped and reset last week, because it was started too early.
>
>
> Ah, I see -- I received the message I quoted *after* I placed a vote
>
It was stopped and reset last week, because it was started too early. I
remember that you were one of the people to request this :-) See my
explanation here https://externals.io/message/111416#111553
On Fri, Aug 21, 2020 at 3:12 PM Paul M. Jones wrote:
> Hi everyone --
>
> 1. Did anyone else her
On Thu, Aug 20, 2020 at 9:13 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le Wed, 19 Aug 2020 21:11:29 +,
> Theodore Brown a écrit :
> > In case anyone wants to view the in-progress STV vote results, I took
> > the same script I made for the Shorter Attribute Syntax RFC and
I wanted to clarify that this is the **restarted* vote on Shorter Attribute
Syntax Change, that means all votes cast between August 11th and 15th have
been reset.
On Wed, Aug 19, 2020 at 12:50 PM Benjamin Eberlei
wrote:
> Hello everyone,
>
> We have started the vote on "Shor
Hello everyone,
We have started the vote on "Shorter Attributes Syntax Change" RFC to
decide one last time on what syntax to choose for the Attributes feature.
https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
The first vote is a vote to say that you have an opinion about attribute
f we
> should allow grouping or not and if accepted, use STV results on the
> prefered prefix symbols/syntax.
>
Yes, that was exactly the same type of vote for "shorter attribute syntax"
RFC.
>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
On Wed, Aug 19, 2020 at 11:01 AM Andreas Leathley
wrote:
> On 19.08.20 10:47, Benjamin Eberlei wrote:
> > One last change that I didn't see yesterday as it was on Github and not
> > this list is the addition of another syntax proposal @{} with the same
> > bene
On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei
wrote:
>
>
> On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
>
>> Hi,
>>
>> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
>> Syntax Change RFC to reflec
On Wed, Aug 19, 2020 at 12:03 AM Theodore Brown
wrote:
> On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei
> wrote:
>
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > I have updated the RFC one last time with as much of the feedback
> > as po
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an exce
On Tue, Aug 18, 2020 at 8:49 AM Aleksander Machniak wrote:
> On 18.08.2020 00:35, Mike Schinkel wrote:
> > 1. Postpone inclusion of attributes until PHP 8.1
>
> +1
>
> I wonder why my suggestion (somewhere in this thread) didn't get any
> attention. Is it because the ship had sailed or it's a ter
On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel wrote:
> I have been following all the lengthy discussions on this topic hoping the
> list would come to consensus. And I had been hoping someone would call the
> following question but since no one else has here goes.
>
> The concept of adding attri
On Mon, Aug 17, 2020 at 5:
14 PM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown
> wrote:
>
> > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei
> wrote:
> > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> wrote:
> > > >
On Mon, Aug 17, 2020 at 2:29 PM Benjamin Eberlei
wrote:
>
>
> On Mon, Aug 17, 2020 at 10:02 AM Peter Bowyer wrote:
>
>> On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei
>> wrote:
>>
>>> We have updated the RFC at
>>> https://wiki.php.net/rfc/shorte
On Mon, Aug 17, 2020 at 10:02 AM Peter Bowyer wrote:
> On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei
> wrote:
>
>> We have updated the RFC at
>> https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we
>> think
>> covers all the discussion a
On Sun, Aug 16, 2020 at 4:47 PM tyson andre
wrote:
> Hi Benjamin,
>
> > We are looking for further feedback from the community.
>
> Thanks, the updated RFC looks much better.
> Some more feedback on why the edge cases are a concern to me,
> and why the lack of an ending delimiter is similar to pa
On Mon, Aug 17, 2020 at 10:59 AM Alexandru Pătrănescu
wrote:
> On Sun, Aug 16, 2020 at 12:36 PM Benjamin Eberlei
> wrote:
> >
> > We have updated the RFC with all (hopefully) of the feedback from this
> > discussion:
> >
> > https://wiki.php.net/rfc/shorter_
On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
wrote:
> On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei
> wrote:
>
> > We have updated the RFC with all (hopefully) of the feedback from
> > this discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_s
We have updated the RFC with all (hopefully) of the feedback from this
discussion:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Most notable changes are:
- A new section with several subsections on the benefits of a closing
delimiter / enclosing syntax.
- A section on grouping pro/con
On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni wrote:
> On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei
> wrote:
> >>
> >> The RFC says that
> >> > The main concern is that @@ has no ending symbol and it's
> inconsistent with the language
>
Following the valid criticisms of us starting the vote too early, we have
closed the vote for this RFC for now.
We look to restart the vote middle next week, so that we can close this
before the Beta 3 release on September 3rd.
We have updated the RFC at
https://wiki.php.net/rfc/shorter_attribute
On Sat, Aug 15, 2020 at 11:47 PM Jakob Givoni wrote:
> This will probably be my only contribution to this thread so I'll keep
> it simple:
>
> Am I in favor of a revote? Yes
> Can I vote myself? No
> Do I think a revote will change anything? No
> Have there been any good arguments for why attribu
On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown
wrote:
> On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison
> wrote:
>
> > > So, a week+ early, then? Surely that means the current vote null
> > > and void, to be reset entirely following a proper discussion period
> > > -- one without concurrent voting
his late in the release cycle
2. want to keep @@, because this is the current syntax (not <<>>)
> On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins
> wrote:
> >
> > On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei
> wrote:
> >
> > >
> > > On Mon,
On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins
wrote:
> On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei
> wrote:
>
> >
> > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer >
> > wrote:
> >
> >>
> >> I have voted no because I asked a question abo
On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer
wrote:
> On Mon, 10 Aug 2020 at 10:15, Rowan Tommins
> wrote:
>
> > I am not a fan of the @@ syntax, and respect what you're trying to do
> with
> > this RFC, but am disappointed you haven't engaged with those of us who
> said
> > that the RFC needs
On Mon, Aug 10, 2020 at 11:16 AM Rowan Tommins
wrote:
> On Mon, 10 Aug 2020 at 09:41, Derick Rethans wrote:
>
> > I've just opened the vote to make sure we don't make a terrible mistake
> > with using the @@ syntax for attributes:
> >
> > [...]
> >
> > Please have a objective look at the table
>
On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown
wrote:
> On Thu, Aug 6, 2020 at 12:30 PM Benas IML
> wrote:
>
> > Hey Theodore,
> >
> > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown
> wrote:
> >
> > > While none of our syntax options are perfect, I believe @@ has the
> > > best long-term tradeoffs
On Thu, Aug 6, 2020 at 9:18 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans a écrit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
> there
On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown
wrote:
> On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans wrote:
>
> > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > Syntax Change RFC to reflect that process:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
a fatal error on PHP 7 parsers or am I seeing something
wrong?
- its not a familiar syntax for PHP developers used to @ in docblocks
>
> Atenciosamente,
> David Rodrigues
>
>
> Em ter., 4 de ago. de 2020 às 11:03, Benjamin Eberlei
> escreveu:
>
>> On Tue, Aug 4, 2020 a
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an exce
On Mon, Aug 3, 2020 at 7:44 PM Benjamin Eberlei wrote:
> Hi,
>
> I am going to pick up a discussion from
> https://github.com/php/php-src/pull/5915 about the @@Jit attribute.
>
> Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
> attribute and
Aug 3, 2020, 11:27 PM Derick Rethans wrote:
>
>> On 3 August 2020 20:20:35 BST, Benjamin Eberlei
>> wrote:
>>
>> >In that case maybe we should rename the attribute to @@DisableJit ?
>> >This
>> >would not clutter the global namespace with a "ji
On Mon, Aug 3, 2020 at 8:51 PM Stanislav Malyshev
wrote:
> Hi!
>
> > Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
> and
> > "function". This trigger mode feels like micro-management for developers
> > and since it has virtually no spotlight in discussions and blog posts
Hi,
I am going to pick up a discussion from
https://github.com/php/php-src/pull/5915 about the @@Jit attribute.
Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
attribute and asked to discuss here.
The reason is that the default tracing JIT is clever to decide itself whe
Hi Dik,
your e-mail has likely been going to spam for many subscribers of the
mailing list, I have just seen it after reading Nikitas comment on the PR.
https://github.com/php/php-src/pull/5867
I am all for this and wanted to bump the thread to the list so that
everyone can see this as well.
Ar
On Thu, Jul 30, 2020 at 6:19 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Question: The key factor of not using @ is due to conflict of
> suppression symbol.
> While we are in a major (where BC breaks are not encourage, but
> tolerable), have we considered the possibility of
I think it has become clear that we need to revisit this syntax question
again, including the elephpant in the room of delaying this feature to 8.1.
The reason is not only Joe's desire to revote on #[], but also that there
are now more syntax proposals such as @[] by Derick or @@ in comments by
Ty
Hi Joe,
Personally I favor #[] myself, but there has been a vote with a substantial
participation choosing @@. Overturning this democratic outcome should
require **significant** technical arguments, otherwise this RFC would
provide problematic precedent for any RFC to be overturned by arbitrary
re
On Sun, Jul 26, 2020 at 3:52 PM Chris Riley wrote:
> Hi all,
>
> Thanks for the feedback so far. In light of the feedback received both here
> and privately, I've made 3 changes to the RFC document:
>
> 1. The original option 1, allowing renaming parameters but not requiring an
> explicit opt in
On Fri, Jul 24, 2020 at 4:00 PM Chris Riley wrote:
> Hi all,
>
> Following up from this I've created a draft RFC:
> https://wiki.php.net/rfc/renamed_parameters will move to in discussion
> once
> I've ensured everything important has been captured.
>
> Regards,
> Chris
>
You added PHP 8.0 as a p
On Fri, Jul 24, 2020 at 3:15 PM Chris Riley wrote:
> On Fri, 24 Jul 2020 at 14:01, Benjamin Eberlei
> wrote:
>
>>
>>
>> On Fri, Jul 24, 2020 at 1:13 PM Chris Riley wrote:
>>
>>> Hi all,
>>>
>>> The named parameters RFC has been accep
On Fri, Jul 24, 2020 at 1:13 PM Chris Riley wrote:
> Hi all,
>
> The named parameters RFC has been accepted, despite significant objections
> from maintainers of larger OSS projects due to the overhead it adds to
> maintaining backwards compatibility as it has now made method/function
> parameter
On Wed, Jul 22, 2020 at 2:40 PM Deleu wrote:
> "Terrible" is the amount of humans having their lives taken by a pandemic.
> This is at most slightly inconvenient for you. The aggressive tone in this
> discussion is extremely unnecessary.
>
After the RFC was voted on for @@, objectively "terrible
On Tue, Jul 21, 2020 at 4:47 PM Sara Golemon wrote:
> On Tue, Jul 21, 2020 at 9:29 AM Nikita Popov wrote:
>
> > Just so people aren't surprised, I plan to start landing implementations
> > for RFCs that are likely to be accepted in advance of the actual vote
> > closure, as we have many RFC vote
On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta wrote:
> Hi Nikita,
>
> I kept my "NO" stance here, as per discussion in
> https://externals.io/message/110004#110005, where I provided (in my
> opinion) good/safe alternatives to arrays as input parameters.
>
> The BC implications on this RFC still
On Wed, Jul 8, 2020 at 10:15 PM Benas IML wrote:
> Hey internals,
>
> I have reopened the voting. It is going to close July 22nd, 2020. I have
> also
> added a "Why allow void return type on constructors/destructors?" section
> which
> I hope internals are going to read and consider before voting
On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels
wrote:
> Hi all,
>
> I'd like to start the discussion of the "Strict operators directive" RFC
> version 1.5. This RFC proposes a new directive strict_operators, which
> limits the type juggling done by operators to avoid unexpected results.
>
> https:
On Thu, Jul 2, 2020 at 11:12 PM Benas IML wrote:
> Hey internals,
>
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
>
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>
> Best regards,
> Benas Seliuginas
>
On Sat, Jun 27, 2020 at 11:57 AM Andrea Faulds wrote:
> Hi,
>
> G. P. B. wrote:
> > https://wiki.php.net/rfc/rename-double-colon-token
>
> I have voted No to this, and I hope I can convince some others to do the
> same.
>
> T_PAAMAYIM_NEKUDOTAYIM is such a famous token that there is probably
> no
ique, and only a small number is usually repeatable. So making them
unique by default and only repeatable on request is the better approach.
>
> Atenciosamente,
> David Rodrigues
>
>
> Em seg., 22 de jun. de 2020 às 13:38, Benjamin Eberlei <
> kont...@beberlei.de> escr
, Jun 8, 2020 at 10:12 AM Benjamin Eberlei
wrote:
> Hello internals,
>
> I have opened voting for four different amendments to the Attributes RFC
>
> https://wiki.php.net/rfc/attribute_amendments
>
> The voting period ends at 2020-06-22 8:00 UTC.
>
> greetings
> Benjamin
>
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
On Tue, Jun 9, 2020 at 2:07 PM Lynn wrote:
>
>
> On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei
> wrote:
>
>> Larry's suggestion about #[Attr] makes an important argument about
>> allowing
>> to declare attributes in code in PHP 7 in a forward compatible
On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
wrote:
> Hi internals,
>
> I discussed the syntax for attributes further with Benjamin, Martin,
> and several other internals developers off-list, and with their
> feedback completed an RFC proposing to use the shorter `@@` syntax
> instead of `<<>>`
1 - 100 of 381 matches
Mail list logo
