Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110460
MIME-Version: 1.0
References: <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CAEPJdumShcZMFSe_u0guVX2RuFf5X9FRp=i+-b62UUvaJiFipQ@mail.gmail.com>
In-Reply-To: <CAEPJdumShcZMFSe_u0guVX2RuFf5X9FRp=i+-b62UUvaJiFipQ@mail.gmail.com>
Date: Wed, 10 Jun 2020 10:11:30 +0200
Message-ID: <CABdc3WrZ3tY=ZWEy93t9T-3Rgfqr6RsBKUB409yh1jKbYN-+sA@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Theodore Brown <theodorejb@outlook.com>, Sara Golemon <pollita@php.net>, carusogabriel34@gmail.com, 
	internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000db51b805a7b66453"
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--000000000000db51b805a7b66453
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

wt., 9 cze 2020 o 13:56 Benjamin Eberlei <kontakt@beberlei.de> napisa=C5=82=
(a):

> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown <theodorejb@outlook.com>
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback completed an RFC proposing to use the shorter `@@` syntax
> > instead of `<<>>` for attributes in PHP 8.
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > The goal is not to bikeshed over subjective syntax preferences,
> > but to address several concrete shortcomings related to verbosity,
> > nested attributes, confusion with generics and other tokens, and
> > dissimilarity to other common languages.
> >
>
> Larry's suggestion about #[Attr] makes an important argument about allowi=
ng
> to declare attributes in code in PHP 7 in a forward compatible way that h=
as
> not been brought up before.
>
> /** @ORM\Entity */
> #[ORM\Entity]
> class User {}
>
> This code would work on PHP 7 and 8.
>
> The #[] syntax would have about equally low breaking potential as @@. It
> would be the same syntax as Rusts, and close to C++/C# syntax.
>

I just noticed a power of Rusts outer attributes which this syntax count
follow in a future.
Following outer attributes in Rust's we could introduce in a future syntax
like

<?php
#![StrictTypes,Module("my_module"),Opcache(save_comments: true)]

The last one used with recently proposed named arguments which could open a
wide range of possibilities IMO.
In Rust adding exclamation mark after hash `#!` imposes to take effect on
the outer scope which inside a file would be the whole file.

Going that path solution like that could possibly supersede `declare`
statement in a future and allow to add compile-time attributes
without breaking the language.
I believe this is very important because any attribute which is not
declared as a core and built-in is not taking an effect.
This way it'd be possible to add new ones in future PHP versions.
Even more with `zend_ast_process` it'd be possible to implement core
attributes which take effect on whole file in extension.

I can imagine this can possibly be discussed to allow attributes for eg.
from ctor to take effect on class but am not 100% sure of it is useful.

Going further with my imagination if we go that path with `#[Attribute]` we
may think of adding error suppression.
I know many don't like error-suppression but sometimes it's helpfull.

In case of core attributes I can imagine a const value can be added renamed
or removed, but the attribute remains the same
then adding error suppression in a future allows to avoid crashing like for
eg.

#@[Jit(Jit::OPTIMISE_SOMETHING)] // where the const may exists or not, but
the Jit attribute does
function foo () {}

In those cases we don't wanna crash the program, we may want it to continue
rather without proper optimisation then not at all.

I just see another use of current error-suppression operator @ to play nice
with attributes.

That's my 50 cents.

Best regards,
Micha=C5=82 Marcin Brzuchalski

--000000000000db51b805a7b66453--