Hi Theodore,
> I meant to say "statement", e.g.
> I suspect it is a statement and not an optional piece of data on a
> statement, like say `public`.
I assume this would boil down to a disagreement on what we mean by statement,
and could be clarified by using whatever that definition was instead
On Tue, Aug 4, 2020 at 8:59 PM 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
> 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
declaration, like say `public`.
--
PHP Internals - PHP
Hi Derick,
> Hi Derick,
>
> I don't agree with the main argument put forward in this RFC:
>
> > The main concern is that @@ has no ending symbol and it's
> > inconsistent with the language that it would be the only
> > declaration or statement in the whole language that has no ending
> >
Hi Derick,
> 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.
1. I feel like "Changes the lexing of **remaining** tokens" should also
Hi all,
> On Aug 4, 2020, at 17:07, 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. As it was the case
> with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary
>
Hi Derick,
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. As it was the case
with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary
vote asking "Are you okay with re-voting on the attribute
On Tue, Aug 4, 2020 at 1:41 PM Christoph M. Becker
wrote:
> On 04.08.2020 at 20:22, Sara Golemon wrote:
> > On Tue, Aug 4, 2020 at 12:01 PM Nikita Popov
wrote:
> >
> >> Sorry, I didn't catch that this message said feature freeze *and
branch*.
> >>
> >> Please do not create a separate PHP-8.0
On 04.08.2020 at 20:22, Sara Golemon wrote:
> On Tue, Aug 4, 2020 at 12:01 PM Nikita Popov wrote:
>
>> Sorry, I didn't catch that this message said feature freeze *and branch*.
>>
>> Please do not create a separate PHP-8.0 branch yet. A separate branch is
>> only needed if anyone wants to start
On Tue, Aug 4, 2020 at 12:22 PM Sara Golemon wrote:
>
> On Tue, Aug 4, 2020 at 12:01 PM Nikita Popov wrote:
>
> > Sorry, I didn't catch that this message said feature freeze *and branch*.
> >
> > Please do not create a separate PHP-8.0 branch yet. A separate branch is
> > only needed if anyone
On Tue, Aug 4, 2020 at 12:01 PM Nikita Popov wrote:
> Sorry, I didn't catch that this message said feature freeze *and branch*.
>
> Please do not create a separate PHP-8.0 branch yet. A separate branch is
> only needed if anyone wants to start landing changes targeting PHP 8.1
> already -- as
On Tue, 4 Aug 2020 at 19:40, Nikita Popov wrote:
> On Tue, Aug 4, 2020 at 7:01 PM Nikita Popov wrote:
>
>> On Tue, Aug 4, 2020 at 9:39 AM Gabriel Caruso
>> wrote:
>>
>>> Good morning Internals!
>>>
>>> This is a reminder that *today* we are Feature Freezing and branching
>>> `PHP-8.0`,
On Tue, Aug 4, 2020 at 7:01 PM Nikita Popov wrote:
> On Tue, Aug 4, 2020 at 9:39 AM Gabriel Caruso
> wrote:
>
>> Good morning Internals!
>>
>> This is a reminder that *today* we are Feature Freezing and branching
>> `PHP-8.0`, following the PHP 8.0 schedule (
>>
On Tue, Aug 4, 2020 at 9:39 AM Gabriel Caruso wrote:
> Good morning Internals!
>
> This is a reminder that *today* we are Feature Freezing and branching
> `PHP-8.0`, following the PHP 8.0 schedule (
> https://wiki.php.net/todo/php80#timetable).
>
> The branch will happen around
>
> - 1 am (+1
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
>
> Patches and comments welcome.
Hi Derick,
I don't agree with
On Tue, 4 Aug 2020, Sara Golemon wrote:
> On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei wrote:
>
> > It provides a small BC break where code written as @[$foo, $bar] =
> > baz(); or $foo = @["bar" => $baz]; will not compile on PHP 8
> > anymore, but that can be easily fixed by writing it
On 04/08/2020 16:19, Sebastian Bergmann wrote:
Am 04.08.2020 um 15:45 schrieb Derick Rethans:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
This is probably a wiki/markup issue: the RFC shows "«Attr»" instead
of "<>" for the original syntax.
Given that every single thread about
On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei wrote:
> It provides a small BC break where code written as @[$foo, $bar] = baz();
> or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can
> be easily
> fixed by writing it with a space between @ and [.
>
> If those are the
On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues
wrote:
> Suggestions:
>
> $(Attribute()) (available)
> $[Attribute()] (available)
> <> 2)>> (like strings escapes)
>
I had someone else suggest $[] to me today as well, funny coincidence :-)
Can you take the "@@ to @[] pull" request as a starting
On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues
wrote:
> Suggestions:
>
> $(Attribute()) (available)
> $[Attribute()] (available)
> <> 2)>> (like strings escapes)
>
The syntax for the first two seems oddly pleasing when used within PHP.
Suggestions:
$(Attribute()) (available)
$[Attribute()] (available)
<> 2)>> (like strings escapes)
About $() syntax:
- Number of required characters: (2+1)
- Has end delimiter: yes
- Allow grouping: yes
- Forward compatibility in PHP 7: yes
- Breaks BC of valid PHP 7 codes: no
Am 04.08.2020 um 15:45 schrieb Derick Rethans:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
This is probably a wiki/markup issue: the RFC shows "«Attr»" instead of
"<>" for the original syntax.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi,
Am 04.08.20 um 15:45 schrieb Derick Rethans:
> Patches and comments welcome.
if the syntax will be changed to having a closing delimiter, I would
really like to have symmetrical delimiters, like @{ }@ or something like
that. ] as a closing delimiter just seems to collide with the array
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
A little nitpick but I don't think that `@@` really signals familiarity
with docblocks.
Nevertheless, I really like `@[...]`. I think it combines best of the both
worlds (little-to-no BC breaks, ending delimiter, etc.) and also looks
aesthetically pleasing.
Best regards,
Benas
On Tue, Aug 4,
Hi internals,
> I've started the vote on
> https://wiki.php.net/rfc/phar_stop_autoloading_metadata
> as announced earlier in https://externals.io/message/110871
> ([RFC] Don't automatically unserialize Phar metadata outside getMetadata())
>
> This adds the mitigations described in
>
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 excemption from the RM Sara as per [2]:
> * Shorter Attribute Syntax
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 asked to discuss here.
>
>
On Tue, 4 Aug 2020 at 08:39, Gabriel Caruso wrote:
> The branch will happen around
>
> - 1 am (+1 day) UTC+8 (SGT)
> - 7 pm UTC+2 (CEST, my timezone)
> - 6 pm UTC+1 (BST)
> - 1 pm UTC-4 (EDT)
>
> Let us know if you have any questions!
>
Will it be livestreamed? /jk
Seriously, it's a great time
Hi Internals,
Voting has ended. The RFC was declined with 14 votes against and 14 votes
in favour.
The second vote shows we don't wanna change exceptions trace into objects
at all.
If I'm not wrong this means that debug_backtrace using objects as
frames instead of arrays has some potential and
Good morning Internals!
This is a reminder that *today* we are Feature Freezing and branching
`PHP-8.0`, following the PHP 8.0 schedule (
https://wiki.php.net/todo/php80#timetable).
The branch will happen around
- 1 am (+1 day) UTC+8 (SGT)
- 7 pm UTC+2 (CEST, my timezone)
- 6 pm UTC+1 (BST)
- 1
Le Tue, 28 Jul 2020 17:57:34 +,
Theodore Brown a écrit :
> Rust chose to use #[] even though it wasn't used by any other language.
> Does that make it a bad fit for Rust? No. But just because Rust uses
> a syntax also doesn't mean it's a good fit for PHP.
For those which like me do not know
Alternatively make it @@Jit("off") only and any other argument will lead to
an error for now.
Then the problem left becomes "Jit" being a very short global class.
On Mon, Aug 3, 2020 at 10:36 PM Benas IML wrote:
> `@@NoJit` sounds pretty alright to me.
>
> On Mon, Aug 3, 2020, 11:27 PM Derick
33 matches
Mail list logo
