Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110819 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38694 invoked from network); 2 Jul 2020 15:31:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Jul 2020 15:31:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 328281804DA for ; Thu, 2 Jul 2020 07:20:54 -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=-0.7 required=5.0 tests=BAYES_05,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-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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, 2 Jul 2020 07:20:53 -0700 (PDT) Received: by mail-ed1-f53.google.com with SMTP id h28so24118691edz.0 for ; Thu, 02 Jul 2020 07:20:53 -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=j76BRAQQJiC+8GX/lnFB8+Lqqj3dVIiJ2S3M6pVn8DQ=; b=QHwkUWmBqA+PPQI6s5Jgqnd/MqItfV/ttaMTwK/JGykfS7bvDkJVaxe36ccNZSYmXJ OzunIAQxI+9TRxJxDmUKNX/evPXdOARlnNKw7Z9Ll7FdamYG1VGBLpQ2Tk943rh4H8B/ 2s8ZmdkAP4rBCLM70OtpCmakdjZwNdCo9ZXWM8htYiGUjtIQ4qwwuqWHt3YUAG9d5Grh D2b6odAhYu8uO6KrrlwEfTdnLRcc8gVFqAdYZA2/6KJW4HsoO+8EKsRZuuWVM9h8uD3f yaK5Ul/HAvBjviLcaJUZhoDNnOc4HrWu8B7wf0ZWG1AtNJBqEiDtBJcFriPAkDUtIlJ+ 027Q== 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=j76BRAQQJiC+8GX/lnFB8+Lqqj3dVIiJ2S3M6pVn8DQ=; b=qVCnrNPepvu61jJ/VhEPXM6liD4BA9TmZLSztItyMPEk+VfgDRpsg0GygduGLFv06+ IscKKtBEFewYkSN6HuHV7UCuubzrOIXqCgnxaOyfBRQ5+lSZorumYe/NWwHjt4BOfdl6 ti5N2+ymea/i2vCGEFFuBTVPjjh4XrpXxB3g7AQ35NUxGiLD3ign7HTLzoWadXoSt6+X 0dRvLjA/B+TzKAWGebUK7lLpbi9UzqiTzgUfWwrRdogTtxRZ89EzGa1obKLg/bI7nRV6 mH6i7mjfnR9f5N4U+eBQfdfxBnOfhkkebrw/51wgJDRwCbT5FvIjWjQgP1JjDSZyHYEC fBaQ== X-Gm-Message-State: AOAM530wPeBONjaHJeRHbK6HfuR14s6xA/LOa0PCy6tvaP2bptLVTJT7 sP+lnmIZZ1Am/6GcfnI5H1WzuKQvmQUcB+JjnUnp6ZXTkyA= X-Google-Smtp-Source: ABdhPJz2qrp669P3sDFqScnv6V/r8VLh1ON4xGmjzbpaVVyIMJ7Uwmqq2fvIxukfiaaNqQ81zZnN9c+a4PknVeDRoCk= X-Received: by 2002:a2e:8199:: with SMTP id e25mr1552066ljg.307.1593699297027; Thu, 02 Jul 2020 07:14:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 2 Jul 2020 16:14:40 +0200 Message-ID: To: Theodore Brown Cc: internals Content-Type: multipart/alternative; boundary="0000000000007a67e405a9760873" Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax From: nikita.ppv@gmail.com (Nikita Popov) --0000000000007a67e405a9760873 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 2, 2020 at 2:13 AM Theodore Brown wrote: > On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote: > > > I've opened voting on the Shorter Attribute Syntax RFC: > > https://wiki.php.net/rfc/shorter_attribute_syntax > > > > Since all RFCs require a primary vote with a 2/3 majority, there is > > a main vote to approve the secondary ranked-choice vote. > > > > For the ranked-choice poll, fill in your first through third syntax > > choices, making sure not to select the same syntax more than > > once. You don't have to vote for all three options, but please > > don't leave gaps. > > > > Voting will end in two weeks, on 2020-07-01. > > Hi internals, > > The Shorter Attribute Syntax RFC vote is now closed. The primary poll > for re-voting on attribute syntax was approved with 50 in favor and 8 > opposed. > > For the secondary ranked-choice poll there are 61 valid ballots. Since > only one syntax can be elected, the quota is floor(61 / 2) + 1 =3D 31. > > Note: one ballot wasn't counted since it selected the same syntax > more than once. However, this does not change the vote outcome. > > In the first round the tally is as follows: > > @@: 34 votes > #[]: 21 votes > <<>>: 6 votes > > So @@ reaches the quota and has been elected as the final attribute > syntax for PHP 8. > > Thank you to everyone who voted! > Hi Theodore, Unfortunately, the RFC failed to mention a small, but important detail: The @@ syntax is ambiguous, as pointed out by Martin Schr=C3=B6der: function (@@X \ Y $param) { } Taking into account that PHP allows whitespace between namespace separators, this can either be interpreted as an attribute "X\Y" on an untyped parameter, or as an attribute "X" on a "\Y" typed parameter. The RFC implementation solves this by treating @@ and the following name as a single token that does not permit whitespace. As such, it will be interpreted as "X" with an "\Y" typed parameter. Now, if this had been explicitly mentioned in the RFC, we could have made an explicit decision to accept this language inconsistency: To forbid whitespace in namespaced names for attributes only, unlike all other places in PHP accepting namespaced names. However, it was not mentioned in the RFC, and apart from the authors of the proposal, I don't think anyone was aware of this ambiguity. Fortunately, there is still a way to resolve this issue in a consistent manner: Change the handling of namespaced names in PHP in general. This is exactly what is proposed in https://wiki.php.net/rfc/namespaced_names_as_token. If that proposal is accepted, then the ambiguity would disappear (and the above example would become a parse error). My plan would be to change the https://wiki.php.net/rfc/namespaced_names_as_token proposal to either only deal with the handling of namespaced names (i.e. as a single, whitespace-free token), or at least separate the other reserved keyword related changes into a separate vote. If that proposal passes, then there should be no issue with adopting the @@ syntax for attributes (unless there are other problems I'm not aware of?) If it does not pass, then we'll have to discuss what we want to do here. Regards, Nikita --0000000000007a67e405a9760873--