Re: [PHP-DEV] Ternary associativity

[Björn Larsson]

Den 2020-07-23 kl. 17:26, skrev Sara Golemon:


On Thu, Jul 23, 2020 at 7:26 AM Nikita Popov  wrote:


PHP currently has an incorrect right-associative ternary operator. In
https://wiki.php.net/rfc/ternary_associativity the use of nested ternaries
was deprecated, and was supposed to become an error in PHP 8.0.

Concurrently with that proposal
https://wiki.php.net/rfc/concatenation_precedence made a very similar
change to the concatenation operator precedence. The difference here is
that this throws a deprecation notice in PHP 7.4 (same), but changes the
behavior in PHP 8.0 (rather than making it an error).

This is a pretty nonsensical outcome, in that the same type of change is
implemented in two different ways. I think it would be good to handle the
ternary change the same way as the concatenation change, i.e. make
ternaries use the correct left-associative behavior in PHP 8.0, rather than
throwing an error.

Disagree.  Consistency is valuable, but the overlap of misusage is

different.

A stacked right-associative ternary will still give a "good" result in the
sense that it's reliably reproducible and meaningful in its output based on
being written for right-associativity.
A concat mixed with other binary ops (e.g. math ops) will NOT typically
give a "good" result since the string being contacted to the numeric then
having its math op applied will result in a nonsense answer at best.

It made sense for the concat change to favor "fixing" old code in ways that
doesn't apply to stacked-ternaries since a similar "fix" there will more
likely be a break.

Strong -1 from me.
-Sara


Would it then make sense to have it as compile time error in 8.0 and
make it right-associativein in e.g. 8.1?

OTOH, when looking in RFC on top 1000 affected composer packages
it looks like having the change in 8.0 might be a way forward...

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Sara Golemon]

On Thu, Jul 23, 2020 at 10:19 AM Sara Golemon  wrote:

> If that's the case, then the solution still seems obvious: Defer
> attributes to 8.1.
>
> After some discussion off list, including Nikita (who is probably closer
to this "problem" than any of the rest of us), I think the best way forward
at the moment is to proceed with the voted on action: Merge attributes
using @@ syntax prior to the feature freeze date.

However, with my RM hat on, I need to feel like we're as sure as we can be
about this syntax before it's public.
I'm willing to extend an additional period (up to the tagging of beta3, in
just under six weeks) for a re-vote on the syntax as changing that will be
less violent of a change than merging the entire implementation after
branching.

I hope this solution is both procedurally appropriate and satisfactory to
all.

-Sara

[PHP-DEV] Re: The @@ is terrible, are we sure we're OK with it?

[Mark Randall]

On 22/07/2020 13:00, Derick Rethans wrote:

- There are lots of grumbles, both on here, room 11, as well as in the
   wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)


From discussions in R11 I want to offer the following example of why 
either option with a closing tag is preferable to allow maximum 
flexibility in future development.


Assume we want to extend attributes to include something a lot of PHP 
features have, an access scope, to only allow accessing annotations from 
within the class itself, or a descendant.


Then we end up with something like :

class Foo {
  @@protected Attr protected int $bar;
}

Contrast that to something with opening and closing tags where they are 
clearly grouped:


class Foo {
  #[protected Attr] protected int $bar;
}



What other syntax might we want to add? Perhaps we want to add a way to 
enforce validation at encounter time with a "checked" keyword.


@@checked protected Attr(1,2,3) protected int $bar

#[checked protected Attr(1,2,3)] protected int $bar

It's much less ambiguous what belongs to what.



Now we could dig ourselves out of this hole using additional tokens 
around @@ such as @@(checked protected Attr) but at which point why not 
just use a mechanism that supports it out of the box?


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 7.4.9RC1 is available for testing

[Derick Rethans]

PHP 7.4.9RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.4.9RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system at
.

Hash values and PGP signatures can be found below or at
.

7.4.9 should be expected in 2 weeks, i.e. on August 6th, 2020.

Thank you, and happy testing!

Regards,
Derick Rethans


php-7.4.9RC1.tar.gz
SHA256 hash: e1aed9aa930d5153ad658225e4794e5e30c4ec8b1c7295c139aa13725542a472
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8WoboACgkQkQ3rRvU+
oxJhkA//ed4/ltBSHe6vlYQLyp+pD5jRWfI7ZCor8Y5yjbiWnbtkRoayY+vrfjGS
YYYUUTXgLvlv/Ic439SUXwgWRAlJfVwGe2Z4KbdzpUjvRjy39FJ4G6uTD9T31F8p
iyFvjhYb+r8Ju8M1CFzRPs1F6FhPQlCPZiP/W0TXrSauXoht1lzlYZvxAGpmoGEh
mOs7Ds9uf7DAjxLtKJ5j4GPgo9388ZFW3mXAz59YXsaQpalNbz48uDbULNGrJ/so
Q5jmcjEg8Ny4ADYAS9yVAlv5/alvekkNxpPI2iSoRNPL2hNVMQnbdgCDdtjDS6S8
/8XyPlb3NuT8mQnOdVWkuVRj0x70SXKigTJ4Zha3MkedRSJxCzG6sGblpo/4FAKN
lQj0TA2iIHPC/O9qP1B7a93kPzd00P6ahEPHyU4Fjo015jqOyga6cJAAbPiA8Qol
GcStzanbl+r3I4C3RereYxxCScsOZbbdYWoatSMauzyYDP9Pb35XqrA28TDmsowR
zqeSd88qzOI1PhZCxQZNEaoEtnHNQHeQU/ZiZ1X9CMZzxq5KQW04uiIxu2TElqnA
ODENukVQs2wZl4X0z4qRlPOKoAsb3CIzLcw3PHjvOkakoypj4EoJ01xGglP3qmgJ
UrpJfa1sUjyFkVQBrOEzhjweSHvl3TLBGQmsqvQQi9Kp2oir+6k=
=G0Kw
-END PGP SIGNATURE-

php-7.4.9RC1.tar.bz2
SHA256 hash: 77d584cef9b167c5b2d2d72167995d7bd9c1f5bdd314db2b404665068094a3bf
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8Wob4ACgkQkQ3rRvU+
oxLO2w//QWW31R+4UkbMKotHZ6lcJ73I48p17Qo5tm9EKrf9RLRgOeW89ZL3ed2G
dTUxKp1etRKT8qLz63MucCcsz6EOHbNq1ObWbVVfQwQ641G+PJ/rytC6rop17Q1Z
g3YbBFxHazlPs0+h2rzm3m9aukF4dM9W2LQ2TXlTfpPKoj2xBVekS/N5Uxp9Ul8i
OB8qHPAufQMPG9OnR7Y5APKh1S0iXR2lVPIOaRGQJP9ft+aAPQiYblDj6kKpXYVc
dfGw8VBhTaoIdlZjJQ1O/U1Ia9jNSyk8r3NiUNR/OqZWgrH2hXhxup9co/63I3wR
pHoSFcu96Ys90UYjmU8ZJqt4mvNFysKddqG6527pIm6zP3RraJ4/QnkDMukOr2PY
jFP4oTox1pmGsuPUyRpDyqMAPBsYmdPY2YWCHBalVqaDDsW/zOSJU3Bu53J740A9
RjCt4qgwtn2De+lEBNa3HY6dQQIDdjpYYpW7V5AxoEfvj+jM6o55lJeJXkKI6v6E
adKZapJe+6pyGOYeicrsUXw1PJCwJcKyYCcUmPsTiAECuPUxREMiuNBO091EbZF/
Hp1hYd/udW3Gi5xC0EkR1a508Eh+UqknP/Bq8Pnw89Xx5OGVMTZUXn5UX1uHYFMq
78zJTJh9cCUwzGbzVBIxNnsTNcz2Dhm3SeuvEykWgs0TYRSOUiA=
=oNfg
-END PGP SIGNATURE-

php-7.4.9RC1.tar.xz
SHA256 hash: 218eabb56713489b11f74c294dd6df27a1f389efaaf8687eeb5e36ee2e9efcbb
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8Wob8ACgkQkQ3rRvU+
oxIryxAAzpuX6RYfcCRFaz7rzW23AAZtlXBiyyH3HvfEXgR9Hfj/958lg7O563iU
6WCB3ggz03U/lFgN/V27RAsqKKlxrwmbVsbwojnk3VDEovUxVmO1Lf6YtUNsTboy
fFNijWJpzE4aTRxNZBKHYhUDNWdngDEeyL6mKXuvkfpvKfbTx6EaW85d3SNbNZel
39DOOJgs1rXBOoEV/RaOWZ4NZFNkauKTsVQhxtPRvB4I3lAyQtMvoXwJqA0BpRWA
hzo46ihA08xlnoWRk0ybnb3pY9Msh/uOV1C3iub6OvvhH7rV/Bboim8nmQi3y8lJ
Ja/dzlksxSsitmyFoCu5jF2KWR9fKhjr6BiFsT6R2CGr++jhD6cxf5kghNBRJhIY
3/9xbEHYXGT4a51nXgY0cjkoyp2nvso7jzc8rwj7EtQrqGopoh9QIquIN09HzltJ
IhQZ08+mwhfBFIR1cUT3bcTkF+Xf2ZW3JgwtpKYXb/tAOeV7SLqdYbk7mwkLpS3L
JX+iVKZs/ICVKoMFosaei93cGV0NDrlkZUebDXhWfN82caY5qzlAKriTNvcLYeBL
TRXY8YAsrf7dhmlMpdB3XMcXkKl524akQbOVJyq8sZL4VEaZt/Ff+wro/iyrhgnR
krm2A5/AJUJsXqKdx5Rny9O+7ljFvB9cVeJoQE2Ntg7mKmJuuvc=
=TZu/
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[David Rodrigues]

I think that we need some symbol that isn't open-and-close like << and >>,
because it will conflict with shift operation, and basically all
open-and-close options are used for other things; or that confuses with
error suppression like @@ and comments like #[].

Maybe we really need a new keyword, so we can apply it "as a function":
attr(Attribute(), Attribute()) function () {...} or attribute().

Or even more complex syntaxes, like: [: Attribute :].


Atenciosamente,
David Rodrigues


Em qui., 23 de jul. de 2020 às 12:32, Benas IML 
escreveu:

> Just to chime in, `<<...>>` does not have any BC implications or problems
> with bit shift operators.
>
> On Thu, Jul 23, 2020, 6:05 PM Marcio Almada  wrote:
>
> > Hi
> >
> > > On Thu, July 23 2020 at 1:26 AM Mark Randall 
> wrote:
> > >
> > > > On 23/07/2020 02:00, Sara Golemon wrote:
> > > > > Regards the vote; I don't believe that @@ has been proven
> unworkable,
> > > > > however if I'm wrong about that, then the second choice selection
> > from the
> > > > > last vote would obviously take precedence.
> > > >
> > > > I don't believe the concern is that we have something unworkable
> > sitting
> > > > in front of us right now, after all if that were the case we would
> not
> > > > be needing to have this conversation as the RFC would already have
> been
> > > > rendered void.
> > > >
> > > > What we do have, is a deep sense of unease that we collectively made
> > the
> > > > wrong decision, based on, in part, incomplete information.
> > > >
> > > > While the initial block to @@ has been remedied by a larger
> > > > language-level change, that the problem existed at all provided a
> clear
> > > > example of the widely unforeseen challenges associated with the @@
> > > > syntax and its lack of closing tags, and focused renewed attention on
> > > > long-term consequences which where perhaps not given enough
> > > > consideration during the vote.
> > > >
> > > > There has been one occurrence already, there will likely be more in
> the
> > > > future. But what specifically will they be and how severe? We likely
> > > > will not know until they happen.
> > >
> > > Hi Mark,
> > >
> > > I don't agree that there "will likely be more in the future". When I
> > > asked Nikita if he could think of any example that would end up being
> > > a problem, the only one he listed was a infinite parser lookahead
> > > requirement if a) attributes were allowed on statements and b)
> > > generics were implemented with curly braces instead of angle brackets.
> > >
> > > He noted that "it's unlikely we'd actually do that" and ended his
> > > email by saying "it is more likely than not, that we will not
> > > encounter any issues of that nature." [1]
> > >
> > > The @ attribute syntax has been used in other C family languages for
> > > years, and to my knowledge hasn't caused any problems in practice.
> > >
> > > It is actually the <<>> variant that is more likely to back us into a
> > > corner when it comes to future syntax like nested attributes (the RFC
> > > authors considered it to cross a line of unacceptable ugliness,
> > > and the alternative `new Attribute` syntax has technical problems).
> > > This may be one reason Hack is moving away from it to @.
> > >
> > > > But what we can say with reasonable confidence is we have an option
> > > > on the table that is technically superior
> > >
> > > I don't agree that #[] is technically superior. The implementation is
> > > virtually identical. The main practical difference is that hash
> > > comments could no longer start with a [ character, which would be
> > > surprising behavior and a larger BC break (there's definitely code in
> > > the wild using this right now).
> > >
> > > If you have a concrete example of syntax that is *likely* to cause a
> > > problem with @@, please share it. From my perspective, @@ is closest
> > > to the syntax used by the majority of C family languages for
> > > attributes, and thus is *least likely* to present future challenges.
> > >
> > > Best regards,
> > > Theodore
> >
> >
> > I was going to reply these same things, but you beat me to it. But just
> to
> > complement, after looking at the patches it became a bit evident that
> > most of the concerns being raised against @@ also work against the
> > other proposals. All have a certain level of BC break due to parsing
> > ambiguity:
> >
> > - @@ can break the silence operator when it's chained (useless anyway)
> > - #[...] breaks comments
> > - <<...>> has problems with bit shift operators
> >
> > From all these tradeoffs I'd rather compromise on breaking the useless
> > chaining of error suppression operators, FOR SURE.
> >
> > I have the impression most of this thread at this point is about personal
> > taste on what was voted rather than technical. Hopefully it's a wrong
> > impression.
> >
> > >
> > > [1]: https://externals.io/message/110568#111053
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Benas IML]

Just to chime in, `<<...>>` does not have any BC implications or problems
with bit shift operators.

On Thu, Jul 23, 2020, 6:05 PM Marcio Almada  wrote:

> Hi
>
> > On Thu, July 23 2020 at 1:26 AM Mark Randall  wrote:
> >
> > > On 23/07/2020 02:00, Sara Golemon wrote:
> > > > Regards the vote; I don't believe that @@ has been proven unworkable,
> > > > however if I'm wrong about that, then the second choice selection
> from the
> > > > last vote would obviously take precedence.
> > >
> > > I don't believe the concern is that we have something unworkable
> sitting
> > > in front of us right now, after all if that were the case we would not
> > > be needing to have this conversation as the RFC would already have been
> > > rendered void.
> > >
> > > What we do have, is a deep sense of unease that we collectively made
> the
> > > wrong decision, based on, in part, incomplete information.
> > >
> > > While the initial block to @@ has been remedied by a larger
> > > language-level change, that the problem existed at all provided a clear
> > > example of the widely unforeseen challenges associated with the @@
> > > syntax and its lack of closing tags, and focused renewed attention on
> > > long-term consequences which where perhaps not given enough
> > > consideration during the vote.
> > >
> > > There has been one occurrence already, there will likely be more in the
> > > future. But what specifically will they be and how severe? We likely
> > > will not know until they happen.
> >
> > Hi Mark,
> >
> > I don't agree that there "will likely be more in the future". When I
> > asked Nikita if he could think of any example that would end up being
> > a problem, the only one he listed was a infinite parser lookahead
> > requirement if a) attributes were allowed on statements and b)
> > generics were implemented with curly braces instead of angle brackets.
> >
> > He noted that "it's unlikely we'd actually do that" and ended his
> > email by saying "it is more likely than not, that we will not
> > encounter any issues of that nature." [1]
> >
> > The @ attribute syntax has been used in other C family languages for
> > years, and to my knowledge hasn't caused any problems in practice.
> >
> > It is actually the <<>> variant that is more likely to back us into a
> > corner when it comes to future syntax like nested attributes (the RFC
> > authors considered it to cross a line of unacceptable ugliness,
> > and the alternative `new Attribute` syntax has technical problems).
> > This may be one reason Hack is moving away from it to @.
> >
> > > But what we can say with reasonable confidence is we have an option
> > > on the table that is technically superior
> >
> > I don't agree that #[] is technically superior. The implementation is
> > virtually identical. The main practical difference is that hash
> > comments could no longer start with a [ character, which would be
> > surprising behavior and a larger BC break (there's definitely code in
> > the wild using this right now).
> >
> > If you have a concrete example of syntax that is *likely* to cause a
> > problem with @@, please share it. From my perspective, @@ is closest
> > to the syntax used by the majority of C family languages for
> > attributes, and thus is *least likely* to present future challenges.
> >
> > Best regards,
> > Theodore
>
>
> I was going to reply these same things, but you beat me to it. But just to
> complement, after looking at the patches it became a bit evident that
> most of the concerns being raised against @@ also work against the
> other proposals. All have a certain level of BC break due to parsing
> ambiguity:
>
> - @@ can break the silence operator when it's chained (useless anyway)
> - #[...] breaks comments
> - <<...>> has problems with bit shift operators
>
> From all these tradeoffs I'd rather compromise on breaking the useless
> chaining of error suppression operators, FOR SURE.
>
> I have the impression most of this thread at this point is about personal
> taste on what was voted rather than technical. Hopefully it's a wrong
> impression.
>
> >
> > [1]: https://externals.io/message/110568#111053
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
>
> Ty,
> Márcio
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Ternary associativity

[Sara Golemon]

On Thu, Jul 23, 2020 at 7:26 AM Nikita Popov  wrote:

> PHP currently has an incorrect right-associative ternary operator. In
> https://wiki.php.net/rfc/ternary_associativity the use of nested ternaries
> was deprecated, and was supposed to become an error in PHP 8.0.
>
> Concurrently with that proposal
> https://wiki.php.net/rfc/concatenation_precedence made a very similar
> change to the concatenation operator precedence. The difference here is
> that this throws a deprecation notice in PHP 7.4 (same), but changes the
> behavior in PHP 8.0 (rather than making it an error).
>
> This is a pretty nonsensical outcome, in that the same type of change is
> implemented in two different ways. I think it would be good to handle the
> ternary change the same way as the concatenation change, i.e. make
> ternaries use the correct left-associative behavior in PHP 8.0, rather than
> throwing an error.
>
> Disagree.  Consistency is valuable, but the overlap of misusage is
different.

A stacked right-associative ternary will still give a "good" result in the
sense that it's reliably reproducible and meaningful in its output based on
being written for right-associativity.
A concat mixed with other binary ops (e.g. math ops) will NOT typically
give a "good" result since the string being contacted to the numeric then
having its math op applied will result in a nonsense answer at best.

It made sense for the concat change to favor "fixing" old code in ways that
doesn't apply to stacked-ternaries since a similar "fix" there will more
likely be a break.

Strong -1 from me.
-Sara

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Sara Golemon]

On Thu, Jul 23, 2020 at 1:26 AM Mark Randall  wrote:

> On 23/07/2020 02:00, Sara Golemon wrote:
> > Regards the vote; I don't believe that @@ has been proven unworkable,
> > however if I'm wrong about that, then the second choice selection from
> the
> > last vote would obviously take precedence.
>
> I don't believe the concern is that we have something unworkable sitting
> in front of us right now, after all if that were the case we would not
> be needing to have this conversation as the RFC would already have been
> rendered void.
>
> What we do have, is a deep sense of unease that we collectively made the
> wrong decision, based on, in part, incomplete information.
>
>
If that's the case, then the solution still seems obvious: Defer attributes
to 8.1.

I know a LOT of people will not be happy about that, but it's the most
responsible thing to do if the threat of forking up is that present and
that dangerous.  There are plenty of cool new toys coming in 8.0, we can
save something for 8.1 and get it *right* instead of shooting ourselves in
the collective foot.

-Sara

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Marcio Almada]

Hi

> On Thu, July 23 2020 at 1:26 AM Mark Randall  wrote:
>
> > On 23/07/2020 02:00, Sara Golemon wrote:
> > > Regards the vote; I don't believe that @@ has been proven unworkable,
> > > however if I'm wrong about that, then the second choice selection from the
> > > last vote would obviously take precedence.
> >
> > I don't believe the concern is that we have something unworkable sitting
> > in front of us right now, after all if that were the case we would not
> > be needing to have this conversation as the RFC would already have been
> > rendered void.
> >
> > What we do have, is a deep sense of unease that we collectively made the
> > wrong decision, based on, in part, incomplete information.
> >
> > While the initial block to @@ has been remedied by a larger
> > language-level change, that the problem existed at all provided a clear
> > example of the widely unforeseen challenges associated with the @@
> > syntax and its lack of closing tags, and focused renewed attention on
> > long-term consequences which where perhaps not given enough
> > consideration during the vote.
> >
> > There has been one occurrence already, there will likely be more in the
> > future. But what specifically will they be and how severe? We likely
> > will not know until they happen.
>
> Hi Mark,
>
> I don't agree that there "will likely be more in the future". When I
> asked Nikita if he could think of any example that would end up being
> a problem, the only one he listed was a infinite parser lookahead
> requirement if a) attributes were allowed on statements and b)
> generics were implemented with curly braces instead of angle brackets.
>
> He noted that "it's unlikely we'd actually do that" and ended his
> email by saying "it is more likely than not, that we will not
> encounter any issues of that nature." [1]
>
> The @ attribute syntax has been used in other C family languages for
> years, and to my knowledge hasn't caused any problems in practice.
>
> It is actually the <<>> variant that is more likely to back us into a
> corner when it comes to future syntax like nested attributes (the RFC
> authors considered it to cross a line of unacceptable ugliness,
> and the alternative `new Attribute` syntax has technical problems).
> This may be one reason Hack is moving away from it to @.
>
> > But what we can say with reasonable confidence is we have an option
> > on the table that is technically superior
>
> I don't agree that #[] is technically superior. The implementation is
> virtually identical. The main practical difference is that hash
> comments could no longer start with a [ character, which would be
> surprising behavior and a larger BC break (there's definitely code in
> the wild using this right now).
>
> If you have a concrete example of syntax that is *likely* to cause a
> problem with @@, please share it. From my perspective, @@ is closest
> to the syntax used by the majority of C family languages for
> attributes, and thus is *least likely* to present future challenges.
>
> Best regards,
> Theodore


I was going to reply these same things, but you beat me to it. But just to
complement, after looking at the patches it became a bit evident that
most of the concerns being raised against @@ also work against the
other proposals. All have a certain level of BC break due to parsing
ambiguity:

- @@ can break the silence operator when it's chained (useless anyway)
- #[...] breaks comments
- <<...>> has problems with bit shift operators

>From all these tradeoffs I'd rather compromise on breaking the useless
chaining of error suppression operators, FOR SURE.

I have the impression most of this thread at this point is about personal
taste on what was voted rather than technical. Hopefully it's a wrong
impression.

>
> [1]: https://externals.io/message/110568#111053
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Ty,
Márcio

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Theodore Brown]

On Thu, July 23 2020 at 1:26 AM Mark Randall  wrote:

> On 23/07/2020 02:00, Sara Golemon wrote:
> > Regards the vote; I don't believe that @@ has been proven unworkable,
> > however if I'm wrong about that, then the second choice selection from the
> > last vote would obviously take precedence.
>
> I don't believe the concern is that we have something unworkable sitting
> in front of us right now, after all if that were the case we would not
> be needing to have this conversation as the RFC would already have been
> rendered void.
> 
> What we do have, is a deep sense of unease that we collectively made the
> wrong decision, based on, in part, incomplete information.
> 
> While the initial block to @@ has been remedied by a larger
> language-level change, that the problem existed at all provided a clear
> example of the widely unforeseen challenges associated with the @@
> syntax and its lack of closing tags, and focused renewed attention on
> long-term consequences which where perhaps not given enough
> consideration during the vote.
> 
> There has been one occurrence already, there will likely be more in the
> future. But what specifically will they be and how severe? We likely
> will not know until they happen.

Hi Mark,

I don't agree that there "will likely be more in the future". When I
asked Nikita if he could think of any example that would end up being
a problem, the only one he listed was a infinite parser lookahead
requirement if a) attributes were allowed on statements and b)
generics were implemented with curly braces instead of angle brackets.

He noted that "it's unlikely we'd actually do that" and ended his
email by saying "it is more likely than not, that we will not
encounter any issues of that nature." [1]

The @ attribute syntax has been used in other C family languages for
years, and to my knowledge hasn't caused any problems in practice.

It is actually the <<>> variant that is more likely to back us into a
corner when it comes to future syntax like nested attributes (the RFC
authors considered it to cross a line of unacceptable ugliness,
and the alternative `new Attribute` syntax has technical problems).
This may be one reason Hack is moving away from it to @.

> But what we can say with reasonable confidence is we have an option
> on the table that is technically superior

I don't agree that #[] is technically superior. The implementation is
virtually identical. The main practical difference is that hash
comments could no longer start with a [ character, which would be
surprising behavior and a larger BC break (there's definitely code in
the wild using this right now).

If you have a concrete example of syntax that is *likely* to cause a
problem with @@, please share it. From my perspective, @@ is closest
to the syntax used by the majority of C family languages for
attributes, and thus is *least likely* to present future challenges.

Best regards,  
Theodore

[1]: https://externals.io/message/110568#111053
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Ternary associativity

[Nikita Popov]

Hi internals,

PHP currently has an incorrect right-associative ternary operator. In
https://wiki.php.net/rfc/ternary_associativity the use of nested ternaries
was deprecated, and was supposed to become an error in PHP 8.0.

Concurrently with that proposal
https://wiki.php.net/rfc/concatenation_precedence made a very similar
change to the concatenation operator precedence. The difference here is
that this throws a deprecation notice in PHP 7.4 (same), but changes the
behavior in PHP 8.0 (rather than making it an error).

This is a pretty nonsensical outcome, in that the same type of change is
implemented in two different ways. I think it would be good to handle the
ternary change the same way as the concatenation change, i.e. make
ternaries use the correct left-associative behavior in PHP 8.0, rather than
throwing an error.

Any thoughts on that?

Regards,
Nikita

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Matteo Beccati]

Hi,

On 22/07/2020 19:09, tyson andre wrote:
> I think that `#[` has its own issues, but am open to re-voting on it.
> For example, the following snippet would get parsed differently in PHP 7.4 
> and PHP 8.0, given a hypothetical JIT annotation for Opcache.
> With <>, it would give people a clear indication that the file 
> required PHP 8.0,
> but a one-line annotation might be silently treated differently in many 
> subtle ways in 7.4.
> It's probably possible to amend the parser make it an error to put the 
> function declaration on the same line or to have other `#` comments
> within a multi-line #[ annotation,
> but I really dislike the special casing it would add.

This is pretty much the reason why I didn't go for '#[' as my first
choice: the false sense of backwards compatibility that can be easily
(and inadvertently) defeated with multiline attributes or inline
function definition.

Since '@@' is causing such unrest, I'd be happy to revisit my choice and
embrace '#[', which was the second option in my vote.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 8.0.0alpha3 is ready for testing

[Gabriel Caruso]

PHP 8.0.0alpha3 has just been released and can be
downloaded from https://downloads.php.net/~carusogabriel

Or use the git tag: `php-8.0.0alpha3`

Windows binaries are available at https://windows.php.net/qa

Please test it carefully, and report any bugs in
the bug system: https://bugs.php.net

8.0.0beta1 should be expected in 2 weeks, i.e. on Aug 06, 2020.

Hash values and PGP signatures can be found below or at
https://gist.github.com/carusogabriel/6e0b8b33ee4dd2da23002863af4de965

Thank you, and happy testing!

Regards,
Sara Golemon & Gabriel Caruso

PHP 8.0.0 Alpha3 Manifest:

```
php-8.0.0alpha3.tar.gz
SHA256 hash:
5bd1074e844ef85063c997d6372ae654080fff27b0ccb36d5597d16994cee1e0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8Wr3IWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj455EACtqoBFzypmD645K4cEvC4NOoYb
Dtokmg6l8Nm1QDwg/ShU8+r0cDw8XNmcdx8tEF3lB+UUCctE6BCDOf4hEF6qKeom
s5qWYWXVDOFQanAWKbkWnSsSgGFoX5DtZ1N0rwKwYsJ+IeB7mNFJB/oaat79mOsQ
ZCbifucsvUIqf9cnMF6ZCo51O5QyEjeMCZwU6pHH3KqFXjQKpgCJkmBVWOo0GrUA
D3uCH9ej46qVnxQ9OgFvb6X500PW/W7KpLC6YXV+lbCTIjOGLe/VwC4dFBfbvgAy
AAnYD+wTs1axEGzyKDo1XgCzQBh5W+/xYTWosllS9Q8vSqgBLR4hKEcijIC/zIXl
NmjxtJKFdtAzjFgkJCE2HKp8gfeEMnJuULcqfaTJGHjOGUakUBUFELq5HNy6v45n
smKQO/ESxoJQuZ/0h2bSGUQU4Aw6OYhwOP1W3wH2WKKM9spKGce/JqCu6dLUsKDe
paB7k5sy14nU9OJ3b1lk7XLiV8DgKf/soTJ3Juspi/UOO4vT6BQkXhMdgOTIF0qU
9TxG1L2xBxzqReQviRSo9HIIONLGVLTm/imEhHGx9O6z/8/kFhif3lFHW+cDKn2H
1nXmJQ4wOwE9EcfYhh8XqYTMX30ExpJx8GaYlcGKK9e8r3DHHlKnRKpWA/+tCPfo
c7+6cEbRZf7n1+n92Q==
=muF5
-END PGP SIGNATURE-

php-8.0.0alpha3.tar.bz2
SHA256 hash:
41ef5740c8cb8d33839c4d7392b9b6a7694105a650aa93be9dfda1287fe27df1
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8Wr3MWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj8GKD/4xLSTBW1vOw852toPWhlMT1FKU
3avZ7LZEHdeqpm+8r9RJ6lZPPVMBpyGj/KkL7mWnyis+FZM9vmuJ1m453cBhDm9O
ztW+N0jqNBgDR/IIVCg1RUSlsZczajLm/EU6wemRADDMtC4VVsFqdBiPjfB/dU1A
eioWulxwTaos3u9AXlxp+43uMWsOAT9NHG8S6wJ42c4j1yBeUJLMunryeDKOXzqp
Ci1fgHvuZjG0Qkk3JGQuRqkgSPoulGBPXjAIz2Mw6pdZkhR7NbB5S2nFitSg6hyG
q07F0REOXLy5MMKtecL/FlP41OgdMFYzP8zGxGnmhPi+MIOfDp8ewtweaxO2aI9a
asC6s2GPeoZm0GsE54r/aVa/s4wj2oDptlIBrtUTJHKCANqCKTkEI3f0d9u0snu/
6yyDaF2Uxq3QUYYUPovwFq4qdQtTKvD12U0KYB0kTEm3dxGz/dGznXEKyQeIFCgs
6uprdGXxzUOIamVzyWtqjU9i8fu1fQQ3bJEK1KpXCWfTrmF9K3TOteUz9zRkcziQ
VR6k4TijvHy4B0qbpbdZADaSrl/au2K7LOL9x3owWsHdOpH1FA/OPk4oEHXFQqz4
RoT0iIq+yF2AAwsnHRSJTJr99HfgqESh3uK+osjXjptxwLt43rNYW2KJOhsb/27D
Mk75LWbyjIoga2Iz8g==
=FhI6
-END PGP SIGNATURE-

php-8.0.0alpha3.tar.xz
SHA256 hash:
83dac88c90bf47fad89bb2425d76243fa0356e462954d652893d05b9593ac6d0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8Wr3MWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj2dVD/9DjeuFPAMbmwTtnXTo/NFAmo8F
vqCAjyIdVu+DAYFGE+Ofxqa6SsXcGlvPcoAtTCyaTQPcy9f+2iqIc+WdF4Y/jYrZ
ERRVbM5Y0MelDlMSBAOCLpG+KEKQUtPPYlkNRlZZalVbcmtQdBarzYC4/1YGvknk
wfPBDLnpsbwnEzEwSCDieVT/0RNczjfg602nUmpHHTXLGxafQ3X8TrU+7IFTppkz
E5OeKw4pwjd8+DWzgN1so93RgXj2LvSAYwZo53j7vKN3Y9PE1pX7USqSm+hXPnIi
iCu/lchrrOyOTBJV2VFbV6ZB4ss4IOMYMoFB8k+PkDW/LCGA9EFSGBTw6eMT75ld
C9c3nVw1L2DA+DP5As0A8fZMmJgAEZ/dJagINF1ZL6mQb5S6QdwymfzDbZdHVlcb
IyVBWpAF6qRMmnDuX/MPt3MHiMu64WAd/az+1yis/UUTVdg0DkgBcu43RkCFofSA
+PMPOz8xIdWr5uAmbEtIgUDky2YRUwTmK0NY2G5g29+1bBYgPXJhtXMFXvI3v9br
i2WeoPv79DjBYB4KjCkcAZClAKOXY4OGGe6zrtgQkL9nRkAfNLESdM2cYKvc24pp
HDpLUS9T73zlgQZeI4+EUnl4dvTI92rlOf6Yb84sov/kC+bro5jH1YKdtuVeJkpM
poGTTUNvTVOxXWAJcA==
=Pk5m
-END PGP SIGNATURE-
```

[PHP-DEV] PHP 7.3.21RC1 is available for testing

[Christoph M. Becker]

PHP 7.3.21RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.3.21RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system.
7.3.21 should be expected in 2 weeks, i.e. on August 6th 2020.

Hash values and PGP signatures can be found below or at
.

Thank you, and happy testing!

Regards,
Stanislav Malyshev & Christoph M. Becker

php-7.3.21RC1.tar.bz2
SHA256 hash:
f42690b0a7a09970a6cd8bd22b2c0d00cc11f1bc1a9716042826bab1e2d57e04
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8WnYUMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2XlQP/3ZirwzyWI736GQBnobbWCwCq7aeTkM0qfsfTn0w
UCfv9RcAByi73crRsTtO90e02y6lLzHo1Ge4+piIQgOsHpIiVUR0LqB3YR+fIEMI
to1d115bMjozy/JsFYVG5LzrkR7Bk5TO2tRoUViS9fd7IDPlOgyAQGci6LVCQpjO
wNayjVDXTNaeIN5l6UctFBpL131TzU0d/VrgohHkY1cIW3JFVWc3mSxxcpjMdDAX
uI4v9tkiWeXsctzYRd/rrHivorcnq3aHVTGo/9uoAqDF9T2l3fR8HqilKi/cO2Ko
ccJ7pLcWeDkrj3Vd4OB9ka8SPH5hvLkK3uPOPTxr6u1kAmuceYHrKXasIl52xj0k
uMksCYWlcZsxDdjxCcAh/epcG0nHYuuD3CviClu916kGy2q9NUcnGMdsW8c4jGiJ
wYobaE6+nu23PiPyGNdihvlHKJduJCL8rdGeshCIAybe9HjyQjXj84RjbYX5nAqc
PPzbPaHFqXYURp8TyIsY5y4AslJCKz4jXSLuHisQIC9QPhe602yvmkgZ6Xdryseg
jur1dJLxe4Q7CscWNCBObqRH/V82nWFL35IbHpT1ZSa6Hsz5DpxyI2jarqCJv+iR
tB8RxsWVUygRvpdBa86PPic0S+wu3ueVMDvau2KM6v7J0hdNaZSsa1OmEOq4UfPB
TlBs
=+6wB
-END PGP SIGNATURE-


php-7.3.21RC1.tar.gz
SHA256 hash:
5b785c242d9a8b5e8ff1b224854ad29f116f42597f5e3552e3c381f1356e3dae
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8WnYUMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2xaYQAJaFoMywLoY4QW6bF8Imu8X5JUP81UeWnqCsnwAV
Ckrj4o+YVMBg02AU8byHUpSa3SJGqp7n49ae6dvULCnfbVX6GlQBh98PX925USh2
oy1lzSalN1ibPYHABO9cNCwkrXOAg4PaqJOxRc2wDVworzsEEDARhWBi699vqBdk
q5mvfC/Yfh4ggbjVX5RpYhdCcMh7jkU5PAfTKAW7Ra27LLGmg17FOcl9d/+t/Vp2
FCJjRiZ9pSRDJUCANiFpjfoeBvhmx+vrlfEg20doBooFTHWgVQX0sAjOAXwfhyXQ
2UhTpqISR+XbksDNkLLsyooL0iUBwnhK5ezkl0xwkg7UzNogguYTpK8YkMStrvka
Q82XSFI6HQERhrqxbWQSs2xsiJKjO1v3pEmMuZ9tZ9WafmgDcQSgyxQb+BKg2ape
NMcZT61jjKTofE/6tA9mTvAxY/V9DZhJvMXt9jBOeSJmxubD2nhu3t+WtxnNE/dP
6frCnmDMAvf/Dk8yPjdw+uGnH/d2ZQWxI1UFCsqLAr1JXnOhK3hR1ZtT4XjJGxyg
yGJgWzgxV20OWIXYn0hAxBuC5IpFxZz5Z5HkAy94YucrYSxn9b4mCbxOpgcgKUmS
2xgiO/J3RT0Lr21H4kUJSrZU/wrcweFtPwR9uxVSOFA7AXnvZyeaR8+mn6OVPDqs
/oMl
=8zBK
-END PGP SIGNATURE-


php-7.3.21RC1.tar.xz
SHA256 hash:
6f9bcff7abdcebbfe398a6e2a4a8c8f0b2a8cbbc0b07f5138c833b63448c1143
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8WnYUMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2sAQP/RVR4BjUDBlI2ui7kli6txJ17wT0A/jtFVhdrHxX
K/e6YNfxfQicOfSWdXDYs5HeHNANPlHUoXpgCMRsiywF9b3OP/ae3z+Wv3e+zzq1
sZ1iZBmWSOxmVMCGi+xvxwyt+MTF+Ik91ybEQOFSloRQvJ/3j2CR3JQUMbiNrFcg
L3sz8K6tXz3NvWRKy6yw+mBOFgXCEN4UnNq4C4vl6DBlPw6sR2Os3pj6qJFDI4GJ
wLguxC4gMMQJbABu61bvbyJeM4knKq78ZK7nj34uMdA5BllfXjpLI+6tYAN5ZPe8
xV9Pl62W2/XwHWN7a3zmY0dg9cU5Wcn4555GK9AME/GmLI8qUERAsq2zWxktXYJw
II3ykJkyGyDpwLrzjcqywfEpcVmtwHPs+xWoMefnHrVFjnuMXKbGf6VZ3h5+sfAO
wfIlpx0UZkPAva8Hoh1+7QrD+uVP/c4zrqaPL86EGxv86GhfqhZ7hrxadb8fknhu
Q1u34f1u4+OMT91rmNYdFvrGCnBomCHnw+819H3dgpAsFWGS2B5I6zqHg/ao7wbg
AY7JPapEVKzoPCwvpzx17YxxXjRarQaul35qaioTt5LXZEayfAKS4ZEPwER+86Wf
XmZiZkCIpweMwNb5futQIDs0JtKDQEO2qmQ/8jDrjdbd6l8Lfa9xznmlt7JVPHRL
N4Ra
=uFDX
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Mark Randall]

On 23/07/2020 08:02, Côme Chilliet wrote:

To be clear, is there anyone who voted for @@ and changed his mind based on new
  information?

Please see the initial discussion here:

https://externals.io/message/110568#111038

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Côme Chilliet]

Le Thu, 23 Jul 2020 07:26:41 +0100,
Mark Randall  a écrit :

> What we do have, is a deep sense of unease that we collectively made the 
> wrong decision, based on, in part, incomplete information.

To be clear, is there anyone who voted for @@ and changed his mind based on new
 information?

I feel like all people wanting to re-vote or discard @@ syntax are the ones
 which voted against it.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php