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

[Joe Ferguson]

On 7/28/2020 08:31, Nikita Popov wrote:

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.


So, does anyone plan to pursue this?

Nikita



Yes. I'll have an RFC to announce shortly. Waiting on one last review 
before sharing here.

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

[Nikita Popov]

On Thu, Jul 23, 2020 at 6:46 PM Sara Golemon  wrote:

> 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.
>

Done.

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.
>

So, does anyone plan to pursue this?

Nikita

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

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] 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

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

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

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

[Mark Randall]

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.


But what we can say with reasonable confidence is we have an option on 
the table that is technically superior, has an implementation ready to 
go, and that will significantly allay the fears of many in internals who 
feel that the @@attributes syntax poses an unnecessary risk of burdening 
future development.


Lets' not commit ourselves to 20+ years of supporting a syntax that we 
already have strong reservations about before it's even out the door.


Mark Randall
marand...@php.net

--
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 Wed, Jul 22, 2020 at 4:29 PM Sara Golemon  wrote:

> Citation Needed.
>
> The '@' token and the T_DOUBLE_AT token come from the lexer as distinct
> values, where is the conflict?
>
> I'm not doubting that there is one, you're quite clever, but at the moment
> you're stating facts not currently in evidence.
>
>
So evidently, this is specifically an issue with attributes in places where
a portion of their name could be mistaken for a type.
AIUI, that's being addressed.

So the complaint is "what if moar ambiguity?" ?
Seems like we're trading a lot of ambiguities.
@@ might be a double error suppress (and might spill over types)
#[..] might be a legit comment
<<...>> might be a freaky combination of bit shifts

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.

-Sara

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

[Dik Takken]

On 22-07-2020 18:51, Derick Rethans wrote:
> This is something that STV is specifically designed to solve. You rank 
> in order by preference. And @@, <<>>, and #[] were all three options.
> 
> In your example, these people would have marked @@ as first, <<>> as 
> second, and #[] as third.

Ah, that was not clear to me. My apologies for the noise.

Thanks,
Dik

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

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

[Кирилл Несмеянов]

However this syntax allows it to be used on 7.4 unlike any other.
 
This means that the initial transition of library functionality to it will be 
very smooth and will not require a separate implementation of polyfills for the 
syntax of doctrine annotations and attributes.
 
With any other syntax, this would require implementing 3 separate attribute 
classes and a bootstrap for them:
 
```
/** @Annotation */
class MyAttribute extends BaseAttribute {}
 
/** @Annotation */
@@\Attribute
class MyAttribute extends BaseAttribute {}
 
abstract class BaseAttribute {}
 
// and bootstrap
 
if (version_compare(PHP_VERSION, ‘8.0’) >= 0) {
    require __DIR__ . ‘/polyfill/MyAttribute.php’;
}
```
 
For Rust-like `#[xxx]` nothing of this is required.
  
>Среда, 22 июля 2020, 20:09 +03:00 от tyson andre :
> 
>Hi Derick,
> 
>> Please, let's do the sensible and use the Rusty #[...] syntax.
>I'd probably re-vote for `<>` given the fact that `@@` may 
>introduce similar parsing ambiguities in the future
>that may interfere with future language changes. (but those issues are not a 
>certainty)
>
>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.
>
>```
>$function = array_filter(
>    $values,
>    #[Opcache\Jit] function(int $x) { return $x % 2 > 0; }
>);
>```
>
>Cheers,
>- Tyson
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit:  https://www.php.net/unsub.php
> 
 
 
--
Kirill Nesmeyanov
 

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

[Sara Golemon]

On Wed, Jul 22, 2020 at 7:00 AM Derick Rethans  wrote:

> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> Yes. Because we voted on it. Twice.


> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token

Citation Needed.

The '@' token and the T_DOUBLE_AT token come from the lexer as distinct
values, where is the conflict?

I'm not doubting that there is one, you're quite clever, but at the moment
you're stating facts not currently in evidence.


> - There is no "end symbol" to make finding occurences easier.

- It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
>
> We knew each of these points at the time of voting. This is not new
information.


> Please, let's do the sensible and use the Rusty #[...] syntax.
>
> Remoaner.  (j/k, you know I love you)

I'm fine with this or any syntax, but FF is 13 days away, you're going to
have to give me something more substantial than "It maybe breaks something
somewhere somehow".

-Sara

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

[Dik Takken]

On 22-07-2020 16:45, Joe Ferguson wrote:
> I would be happy to author an RFC on replacing @@ with #[] but based on
> Larry's comments it sounds like the weighted voting already solved this
> issue for us? We as internals just need to decide that @@ isn't a solution
> and defer to the next ranked vote? I'd be the first one to +1.

That means we effectively disregard the preferences of the ones who
voted for the @@ syntax. We do not know what the @@ voters would have
chosen if the choice was between << >> and #[]. In case the @@ voters
have a preference for << >> the result could turn out differently. The
only way to know is to take another vote.

Regards,
Dik Takken

-- 
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?

[Stanislav Malyshev]

Hi!

> I know we've voted twice on this already, but are we really sure that 
> the @@ syntax is a good idea?

I think it's not a very good idea, and <<>> was just fine, but a lot of
folks apparently voted for it. Would be nice to see their opinion and
how they answer your concerns. I'm not sure it's proper to override the
vote unless there are some severe technical concerns that make that
choice impossible.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
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?

[tyson andre]

Hi Derick,

> Please, let's do the sensible and use the Rusty #[...] syntax.

I'd probably re-vote for `<>` given the fact that `@@` may introduce 
similar parsing ambiguities in the future
that may interfere with future language changes. (but those issues are not a 
certainty)

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.

```
$function = array_filter(
    $values,
    #[Opcache\Jit] function(int $x) { return $x % 2 > 0; }
);
```

Cheers,
- Tyson
--
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 Wed, July 22 2020 at 7:00 AM Derick Rethans  wrote:

> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
> 
> - 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/)
> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
> 
> Please, let's do the sensible and use the Rusty #[...] syntax.

Hi Derick,

Most of the comments in that Reddit thread appear to be positive or
neutral, and in the earlier community poll, the @@ syntax received by
far the most votes 
(https://www.reddit.com/r/PHP/comments/h06bra/community_poll_attribute_syntax/).
So while some in the community may prefer a different syntax, this
doesn't seem to reflect the majority.

If @@ actually has parsing issues, then I would agree that we need to
pick another syntax. But there aren't any issues following Nikita's
RFC to treat namespaced names as tokens. Please check out the
implementation and let me know if you find any problems:
https://github.com/php/php-src/pull/5796.

While most would like to have a single @ character for attributes,
since this isn't possible @@ is the closest alternative, and it
shouldn't present any parsing issues that wouldn't also affect a
single @ character. Of course it will always be possible to think of
theoretical ambiguities with unconventional future syntax, but in
practice this hasn't been an issue for the many other languages using @.

One of the benefits of @@ is actually making it easier to find
occurrences. <<>> is problematic here since these characters also
occur in heredocs/nowdocs and bit shifts. And the ending bracket of
#[] is also used for arrays, so it's not clear that this is very
helpful, either.

The benefit of #[] being exactly the same as another language was
considered in the Shorter Attribute Syntax RFC, but apparently most
voters didn't feel that this outweighed the downsides of a larger BC
break, extra verbosity, and possible confusion with comments.

If there isn't an actual technical problem with the implementation, I
don't think it would be appropriate to hold another vote, or discard
the first preference vote of all those who preferred the @@ syntax.

Best regards,
Theodore
--
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?

[Derick Rethans]

On Wed, 22 Jul 2020, Dik Takken wrote:

> We do not know what the @@ voters would have chosen if the choice was 
> between << >> and #[]. In case the @@ voters have a preference for 
> <<>> the result could turn out differently. The only way to know is to 
> take another vote.

This is something that STV is specifically designed to solve. You rank 
in order by preference. And @@, <<>>, and #[] were all three options.

In your example, these people would have marked @@ as first, <<>> as 
second, and #[] as third.

cheers,
Derick

-- 
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 22/07/2020 17:43, Dik Takken wrote:

That means we effectively disregard the preferences of the ones who
voted for the @@ syntax. We do not know what the @@ voters would have
chosen if the choice was between << >> and #[]. In case the @@ voters
have a preference for << >> the result could turn out differently. The
only way to know is to take another vote.


Yes we do - it was a ranked choice vote where voters selected their 
first, second and third preferences.


If @@ is eliminated, the second choice of all those who voted for it as 
their first choice is already known.


Mark Randall

--
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?

[Sebastian Bergmann]

Am 22.07.2020 um 16:45 schrieb Joe Ferguson:

We as internals just need to decide that @@ isn't a solution
and defer to the next ranked vote? I'd be the first one to +1.


Makes sense to me; +1.

--
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?

[Joe Ferguson]

Hello, Internals,

I would be happy to author an RFC on replacing @@ with #[] but based on
Larry's comments it sounds like the weighted voting already solved this
issue for us? We as internals just need to decide that @@ isn't a solution
and defer to the next ranked vote? I'd be the first one to +1.

On Wed, Jul 22, 2020 at 9:38 AM Gabriel Caruso 
wrote:

> On Wed, 22 Jul 2020 at 14:00, Derick Rethans  wrote:
>
> > Hi all,
> >
> > I know we've voted twice on this already, but are we really sure that
> > the @@ syntax is a good idea?
> >
> > - 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/)
> > - It has the distinct possibility to cause further parsing issues, akin
> >   to what ended up happening with what Nikita is addressing at
> >   https://wiki.php.net/rfc/namespaced_names_as_token
> > - There is no "end symbol" to make finding occurences easier.
> > - It is a syntax *no other language* uses.
> > - @ is never going to go away, so the possibility of @@ moving to @ is
> >   also 0.
> >
> > Please, let's do the sensible and use the Rusty #[...] syntax.
> >
> > cheers,
> > Derick
> >
> > --
> > 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
> >
> >
> Hello Derick.
>
> I do understand your concerns, and I appreciate that you've reached out.
>
> Although we are very close to the Feature Freeze date for PHP 8.0 (
> https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for
> this specific case and let you (or someone), create an RFC proposing to
> change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2),
> and that only!
>
> I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as
> well.
>
> -- Gabriel Caruso
>


-- 
- Joe Ferguson
JoeFerguson.me
osmihelp.org

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

[Gabriel Caruso]

On Wed, 22 Jul 2020 at 14:00, Derick Rethans  wrote:

> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> - 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/)
> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
>
> Please, let's do the sensible and use the Rusty #[...] syntax.
>
> cheers,
> Derick
>
> --
> 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
>
>
Hello Derick.

I do understand your concerns, and I appreciate that you've reached out.

Although we are very close to the Feature Freeze date for PHP 8.0 (
https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for
this specific case and let you (or someone), create an RFC proposing to
change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2),
and that only!

I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as
well.

-- Gabriel Caruso

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

[Кирилл Несмеянов]

I completely agree with this statement.

Moreover, I had to write a full-fledged preprocessor in order to implement 
library functionality, suitable for both attributes and doctrine annotations 
(for version 7.4 and below).
 
Rust-like syntax (#[xxx]) is both visually pleasing and creates much less 
problems when implementing such functionality.
 
Note how easy it will be to adapt the new attribute syntax to support them 
using the doctrine annotation reader:
https://habrastorage.org/webt/w-/dv/vf/w-dvvfygpwdtsmjlcyrr9qxocd0.png
 
The currently accepted "atat" syntax requires the implementation of 4 classes 
and a bootstrap file that forcibly loads the necessary ones and replaces the 
files for a specific version of the language. This is exactly the reason why I 
had to write a preprocessor...
 
>Среда, 22 июля 2020, 16:58 +03:00 от Côme Chilliet < 
>come.chill...@fusiondirectory.org >:
> 
>Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
>Derick Rethans < der...@php.net > a écrit :
>> Please, let's do the sensible and use the Rusty #[...] syntax.
>This syntax is the one I liked the less in the proposed choices, given # is
> used for comments.
>
>Wouldn’t #[] cause more parsing issues than @@?
>
>What would be the rule, it’d be illegal to start a comment content with '['?
>
>Côme
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit:  https://www.php.net/unsub.php
>  
 
 
--
Kirill Nesmeyanov
   
--
 
--
Kirill Nesmeyanov
 

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

[David Rodrigues]

My suggestion is the tilde (~). Currently is used only as the bitwise NOT
operator, but in this context seems to not have any problem.

~ Attribute1(~1)
~ Attribute2(...)
function withAttribute() { ... }

Or then we could use another more detailed syntax:

<-- Attribute(...), ... -->
:: Attribute(...), ...

Or even create a new keyword like:

with Attribute(...), ...
function withAttribute() { ... }

And in last case, just use nothing but the attribute itself as a prefix:

Attribute(...) function withAttribute() {...}


Atenciosamente,
David Rodrigues


Em qua., 22 de jul. de 2020 às 10:58, Côme Chilliet <
come.chill...@fusiondirectory.org> escreveu:

> Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
> Derick Rethans  a écrit :
> > Please, let's do the sensible and use the Rusty #[...] syntax.
>
> This syntax is the one I liked the less in the proposed choices, given # is
>  used for comments.
>
> Wouldn’t #[] cause more parsing issues than @@?
>
> What would be the rule, it’d be illegal to start a comment content with
> '['?
>
> Côme
>
> --
> 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?

[Daniel Martín Spiridione]

+1

El mié., 22 jul. 2020 a las 9:00, Derick Rethans ()
escribió:

> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> - 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/)
> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
>
> Please, let's do the sensible and use the Rusty #[...] syntax.
>
> cheers,
> Derick
>
> --
> 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?

[Côme Chilliet]

Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
Derick Rethans  a écrit :
> Please, let's do the sensible and use the Rusty #[...] syntax.

This syntax is the one I liked the less in the proposed choices, given # is
 used for comments.

Wouldn’t #[] cause more parsing issues than @@?

What would be the rule, it’d be illegal to start a comment content with '['?

Côme

--
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?

[Larry Garfield]

On Wed, Jul 22, 2020, at 7:49 AM, Brent Roose wrote:
> Doesn't it make the most sense to re-vote the syntax? I'd consider the 
> previous vote to be invalid given the parsing issues that weren't 
> listed in the RFC.
> 
> A re-vote seems the most fair: if the majority still prefers @@, then 
> so be it. Otherwise the syntax changes once again, before 
> feature-freeze. I suppose the RMs should have a final say in this 
> descision?
> 
> Kind regards
> Brent

One of the advantages of having conducted it as a ranked-choice-vote is that we 
can easily disqualify the @@ option and then recount with just the other two, 
counting @@ supporters' second choice.  No new vote is needed, unless we think 
a significant number of people would have changed their minds between << >> and 
#[ ] since then.  (I think that's unlikely, personally.)

IIRC, it looked like #[ ] would win that runoff but it's easy enough to 
recompute and be sure.

I agree this is ultimately an RM decision for how to proceed; my recommendation 
would be to Make A Call(tm) if the parsing issues of @@ are significant enough 
to disqualify it, and if so, recompute the vote as above and go with the result.

@@ may be easier to type than the others, but at the end of the day the parsing 
problems it introduces seem like the killer blow to me.

--Larry Garfield

-- 
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?

[Brent Roose]

Doesn't it make the most sense to re-vote the syntax? I'd consider the previous 
vote to be invalid given the parsing issues that weren't listed in the RFC.

A re-vote seems the most fair: if the majority still prefers @@, then so be it. 
Otherwise the syntax changes once again, before feature-freeze. I suppose the 
RMs should have a final say in this descision?

Kind regards
Brent

> On 22 Jul 2020, at 14:46, Benjamin Eberlei  wrote:
> 
> 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" (or bad) reasons
> for this patch have been found though, that can only be softened by
> changing token parsing for namespaces.
> 
> This is not a subjective opinion.
> 
> 
>> On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans  wrote:
>> 
>>> Hi all,
>>> 
>>> I know we've voted twice on this already, but are we really sure that
>>> the @@ syntax is a good idea?
>>> 
>>> - 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/)
>>> - It has the distinct possibility to cause further parsing issues, akin
>>>  to what ended up happening with what Nikita is addressing at
>>>  https://wiki.php.net/rfc/namespaced_names_as_token
>>> - There is no "end symbol" to make finding occurences easier.
>>> - It is a syntax *no other language* uses.
>>> - @ is never going to go away, so the possibility of @@ moving to @ is
>>>  also 0.
>>> 
>>> Please, let's do the sensible and use the Rusty #[...] syntax.
>>> 
>>> cheers,
>>> Derick
>>> 
>>> --
>>> 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
>>> 
>>> 
>> 
>> --
>> Marco Aurélio Deleu
>> 

--
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?

[G. P. B.]

On Wed, 22 Jul 2020 at 13:39, 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.
>

When the voted syntax is technically infeasible due to parser issues
which can only be resolved by another RFC, albeit a sensible one,
I would say this is indeed a terrible choice.

I personally prefer <<...>> but I can accept Rust's syntax more easily
than @@ which seems to come from a preconception that it will
transition to @ many moons in the future which is completely bonkers.

Best regards

George P. Banyard

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

[Benjamin Eberlei]

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" (or bad) reasons
for this patch have been found though, that can only be softened by
changing token parsing for namespaces.

This is not a subjective opinion.


> On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans  wrote:
>
> > Hi all,
> >
> > I know we've voted twice on this already, but are we really sure that
> > the @@ syntax is a good idea?
> >
> > - 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/)
> > - It has the distinct possibility to cause further parsing issues, akin
> >   to what ended up happening with what Nikita is addressing at
> >   https://wiki.php.net/rfc/namespaced_names_as_token
> > - There is no "end symbol" to make finding occurences easier.
> > - It is a syntax *no other language* uses.
> > - @ is never going to go away, so the possibility of @@ moving to @ is
> >   also 0.
> >
> > Please, let's do the sensible and use the Rusty #[...] syntax.
> >
> > cheers,
> > Derick
> >
> > --
> > 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
> >
> >
>
> --
> Marco Aurélio Deleu
>

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

[Lynn]

On Wed, Jul 22, 2020 at 2:39 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.
>

Hi,

If you want to get nitpicky about the definition:

adjective: *terrible*

   1. 1.
   extremely bad or serious.
   "a terrible crime"

I agree with the above posters that @@ for annotations is a terrible
syntax. My choice (if I could vote) would also be the rust variant.

Regards,
Lynn

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

[Jakub Zelenka]

Hi,

On Wed, Jul 22, 2020 at 1:00 PM Derick Rethans  wrote:

> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>

I agree that @@ is really bad. Personally I'd prefer <<...>> but #[...]
seems fine as well (although it's a minor BC break as there could be a
valid comment). I think there are more people that are fine with both
<<...>> and #[...] but don't like @@. Maybe having an option to vote for
more options would be more suitable here or something where it's possible
to vote against @@ rather than just pick one option.

Cheers

Jakub

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

[Deleu]

"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.

On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans  wrote:

> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> - 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/)
> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
>
> Please, let's do the sensible and use the Rusty #[...] syntax.
>
> cheers,
> Derick
>
> --
> 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
>
>

-- 
Marco Aurélio Deleu

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

[Michał Marcin Brzuchalski]

Hi Derick,

śr., 22 lip 2020 o 14:00 Derick Rethans  napisał(a):

> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> - 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/)
> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
>
> Please, let's do the sensible and use the Rusty #[...] syntax.
>

I agree with all the above arguments.

Is there a place (before feature-freeze) and a way to revote it?
What should be the procedure then?
Does it mean the RFC process has an issue and how could it be fixed?

Cheers,
Michał

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

[Benas IML]

Also, +1. I don't really care whether we switch back to `<<...>>` or
`#[...]` but I think `@@` was a bad choice and thus, I think it would be a
much more sensible decision to change the syntax again. At least for the
sake of not running into new ambiguities and in order to stay more similar
with other languages.

On Wed, Jul 22, 2020, 3:00 PM Derick Rethans  wrote:

> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>
> - 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/)
> - It has the distinct possibility to cause further parsing issues, akin
>   to what ended up happening with what Nikita is addressing at
>   https://wiki.php.net/rfc/namespaced_names_as_token
> - There is no "end symbol" to make finding occurences easier.
> - It is a syntax *no other language* uses.
> - @ is never going to go away, so the possibility of @@ moving to @ is
>   also 0.
>
> Please, let's do the sensible and use the Rusty #[...] syntax.
>
> cheers,
> Derick
>
> --
> 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?

[Sebastian Bergmann]

Am 22.07.2020 um 14:00 schrieb Derick Rethans:

Please, let's do the sensible and use the Rusty #[...] syntax.


+1

--
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?

[Marco Pivetta]

 


On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans  wrote:

> Hi all,
>
> I know we've voted twice on this already, but are we really sure that
> the @@ syntax is a good idea?
>

Pretty much clear that @@ is a bad choice - it was picked due to
familiarity of some folks with java annotations,
but it is clear that rust-ish annotations with a clear delimiter have
technical advantages in parsing and future scope/support.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[Derick Rethans]

Hi all,

I know we've voted twice on this already, but are we really sure that 
the @@ syntax is a good idea?

- 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/)
- It has the distinct possibility to cause further parsing issues, akin 
  to what ended up happening with what Nikita is addressing at 
  https://wiki.php.net/rfc/namespaced_names_as_token
- There is no "end symbol" to make finding occurences easier.
- It is a syntax *no other language* uses.
- @ is never going to go away, so the possibility of @@ moving to @ is 
  also 0.

Please, let's do the sensible and use the Rusty #[...] syntax.

cheers,
Derick

-- 
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