Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Benjamin Eberlei
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 >

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Derick Rethans
On Tue, 4 Aug 2020, Levi Morrison wrote: > > I agree with Theodore's points, including that this is metadata on a > > declaration, not a declaration itself. > > Is this technically true? I haven't peeked at the grammar. I suspect > it is a declaration and not an optional piece of data on a > dec

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Derick Rethans
On Tue, 4 Aug 2020, Pedro Magalhães wrote: > I'd like to reinforce the idea that this RFC (as all RFCs) needs a > Yes/No primary vote which should attain a 2/3 majority to pass. I'll make that clear in the RFC, that was obviously my intention. cheers, Derick -- PHP 7.4 Release Manager Host of

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Rowan Tommins
On Wed, 5 Aug 2020 at 13:20, Benjamin Eberlei wrote: > > It looks nice for a simple attribute like @@Jit, or for a one without > arguments like the used @@Deprecated, but as soon as there are more than > one, and they each get arguments, enclosing them has its own benefits over > them just standi

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Theodore Brown
On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei wrote: > 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: >

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread David Rodrigues
A new suggestion: @attr(...). It could be used on future for other syntaxes and should be supersedes the error supression. So will be a BC exclusively for @attr() error supression for attr() function. But it is few verbose and easy to understand. With error supression remotion (9.0?) it could be us

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Rowan Tommins
On 05/08/2020 18:10, David Rodrigues wrote: With error supression remotion (9.0?) it could be used for other new features easily. Just to re-iterate something that I'm pretty sure has been said before: the chance of removing the error suppression operator in PHP 9.0 is approximately zero, an

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Derick Rethans
On Wed, 5 Aug 2020, Rowan Tommins wrote: > On Wed, 5 Aug 2020 at 13:20, Benjamin Eberlei wrote: > > > It looks nice for a simple attribute like @@Jit, or for a one > > without arguments like the used @@Deprecated, but as soon as there > > are more than one, and they each get arguments, enclosi

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Derick Rethans
On Tue, 4 Aug 2020, Theodore Brown wrote: > > #[Attr1, Attr2] # 15 chars > > @@Attr1 @@Attr2 # 15 chars > > # 4 lines, 53 chars not counting whitespace > @[ > AttrWithParam("foobar"), > SomeOtherAttr("fizzbuzz"), > ] > > # 2 lines, 52 chars > @@AttrW

Re: [PHP-DEV] Re: @@Jit Attribute Considerations

2020-08-05 Thread Dmitry Stogov
My solution: - remove doc-comment trigger. It doesn't make sense. - add @@Jit("off") only. Later we may extend this. On Tue, Aug 4, 2020 at 11:11 AM Benjamin Eberlei wrote: > On Mon, Aug 3, 2020 at 7:44 PM Benjamin Eberlei > wrote: > > > Hi, > > > > I am going to pick up a discussion from > >

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

2020-08-05 Thread Derick Rethans
On Wed, 5 Aug 2020, Rowan Tommins wrote: > On 05/08/2020 18:10, David Rodrigues wrote: > > > With error supression remotion (9.0?) it could be used for other new > > features easily. > > > Just to re-iterate something that I'm pretty sure has been said > before: the chance of removing the erro