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 <benas.molis....@gmail.com>
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 <marcio.w...@gmail.com> wrote:
>
> > Hi
> >
> > > On Thu, July 23 2020 at 1:26 AM Mark Randall <marand...@php.net>
> 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
> >
> >
>
