Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111154 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47217 invoked from network); 23 Jul 2020 16:37:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Jul 2020 16:37:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EE92E180531 for ; Thu, 23 Jul 2020 08:32:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 23 Jul 2020 08:32:00 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id y18so3479238lfh.11 for ; Thu, 23 Jul 2020 08:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KXGl96Js3RDBCr0ub/+ugRanDZxRTlDKDxhxjzSBzCI=; b=PkkMql8UtItrmIUzESLu46NXZhO2H1s+o69mQ6PReZY72g3twz1g9MNRxHqJdIcxNK DoE1Nm/vF3iSQLWRz4EIEefIg16KYJB5v0AZuP7V9B+uzHD5A4yfCX+Ztt8wFtOZN4kx FIgzwvA4+Xf8L10ABQKeg+dO4ykohG0lxSd93nCakgB0Dughd2+oNSZ+S5GCmXH4IAn5 KOvjaL87t+M1HgGZJb0BGAk78ZMC7SBqEY1l13cDUwv2z9C1WcAIgMVSCDjxfei3vXEX 6JrzWwXy0I8fyjmn/7mLBrGh0HQ6E6Hhj2dJV4+jIdWYBiU3NvxnpjZh+2YW1mcPbI// c+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KXGl96Js3RDBCr0ub/+ugRanDZxRTlDKDxhxjzSBzCI=; b=X/5cAa04nvWrorZnUCKOk75LFeArFdVlh4h+mL7HzWnW+nmzlxNB5ZSHsCRYSNQna9 qfzSK2EPq/tiMPJiaZ6N6uypqqMfSJ4y93cT+PajxpCW2dJk6FISAa3kszZZTmft81bx pEy+h9rnLF+UpxcOa6hWdClouZ1Fbjm2z7nDQ2CSloCXb4GP8iqHvXp46VaPVRUwfO8q Hf9CT9kpqUJ7IBNnLmQSUQKh5EM3ZOFekYMLsgkEjw1tPSBdUkzD8t655ySTI7TBWy0H FxDqKL7H89XdwOzlyybWbcDYRpx66Mt2AMyREaIWL/Zl6IEB7Ggu1ZtoqgUjdjSu6/r+ zAXA== X-Gm-Message-State: AOAM531FaPZLxpkVD1OltAdaYe7Ohlkzf3unLRJLs3jeNhJIdEYmHpj2 pcoeQ8bzKJ5TcyiWwkSDbuMp3m8qHepK64gn4o0= X-Google-Smtp-Source: ABdhPJxUCta2SqRIZZber9HpOgj1zGrE3GZSoO5zeOf6qNGzk9pkEJnKnlBMA9LaTIphXvWXP7aKNEiy3lPaarPrElw= X-Received: by 2002:a19:c206:: with SMTP id l6mr2540704lfc.152.1595518318859; Thu, 23 Jul 2020 08:31:58 -0700 (PDT) MIME-Version: 1.0 References: <1ed9899c-3816-4646-bad7-4110e4a68978@DM3NAM05FT049.eop-nam05.prod.protection.outlook.com> In-Reply-To: Date: Thu, 23 Jul 2020 18:31:45 +0300 Message-ID: To: Marcio Almada Cc: Theodore Brown , Mark Randall , "internals@lists.php.net" Content-Type: multipart/alternative; boundary="000000000000a0dac605ab1d8e82" Subject: Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it? From: benas.molis.iml@gmail.com (Benas IML) --000000000000a0dac605ab1d8e82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 unworkabl= e, > > > > 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 no= t > > > be needing to have this conversation as the RFC would already have be= en > > > 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 cle= ar > > > 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 t= he > > > 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 t= o > 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=C3=A1rcio > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --000000000000a0dac605ab1d8e82--