Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110463
To: =?iso-8859-2?Q?Micha=B3_Brzuchalski?= <michal.brzuchalski@gmail.com>,
	Benjamin Eberlei <kontakt@beberlei.de>
CC: Sara Golemon <pollita@php.net>, "carusogabriel34@gmail.com"
	<carusogabriel34@gmail.com>, internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter attribute syntax
Thread-Index: AQHWOgIv0rCwDWp4oECJgOMrWx9MxKjQNb8AgAFTugCAAIAn3w==
Date: Wed, 10 Jun 2020 15:51:03 +0000
Message-ID:
 <BYAPR05MB65357F5D4B14EC6AB8E754A9DE830@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CAEPJdumShcZMFSe_u0guVX2RuFf5X9FRp=i+-b62UUvaJiFipQ@mail.gmail.com>,<CABdc3WrZ3tY=ZWEy93t9T-3Rgfqr6RsBKUB409yh1jKbYN-+sA@mail.gmail.com>
In-Reply-To:
 <CABdc3WrZ3tY=ZWEy93t9T-3Rgfqr6RsBKUB409yh1jKbYN-+sA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [mADt6pILHMwSY52XqHlzE+ArG/as7PfI]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 2ba16873-24d2-458d-11ee-08d80d5614dc
x-ms-traffictypediagnostic: BN8NAM11HT167:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 L66VwFf4jf/LFWwi59J06Xyr3JLBtZqD4ip4k4ct3OrNeBPswyCuVCR1oqW1Jk+qlH5FRPzVCKiBwcquUe6+LhjH0mKd2338BE0sXjF+iiFS0F7ZOMCKhCQSBiIWnrUt3R2ziBRIoX5bhjZBHabF9948jKEBPKoFF6Ikze90FwdelLrnAMxZARyhqE6VQy91XB3SIcbMI6+fyLh3ngKpzg==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 bPXJ+mZGGA6ipYOXjoL8v8/Q4WEIWEXNkBV4J8pdXQN2WBFly0STgM817tSRTUyOxwNOzg2XiPNPZ7ip5Ms40iZNDNTOiWoxEoR+oQg3UrHUExahSDe795pyljQtZ82Ozc6HhaYAk11Hc+OkpQnrrw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ba16873-24d2-458d-11ee-08d80d5614dc
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2020 15:51:04.0021
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM11HT167
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: theodorejb@outlook.com (Theodore Brown)

On Wed, June 10, 2020 at 3:11 AM Micha=B3 Brzuchalski <michal.brzuchalski@g=
mail.com> wrote:=0A=
=0A=
> I just noticed a power of Rusts outer attributes which this syntax=0A=
> count follow in a future. Following outer attributes in Rust's we=0A=
> could introduce in a future syntax like=0A=
> =0A=
>     <?php=0A=
>     #![StrictTypes,Module("my_module"),Opcache(save_comments: true)]=0A=
>=0A=
> The last one used with recently proposed named arguments which could=0A=
> open a wide range of possibilities IMO. In Rust adding exclamation=0A=
> mark after hash `#!` imposes to take effect on the outer scope which=0A=
> inside a file would be the whole file.=0A=
> =0A=
> Going that path solution like that could possibly supersede=0A=
> `declare` statement in a future and allow to add compile-time=0A=
> attributes without breaking the language. I believe this is very=0A=
> important because any attribute which is not declared as a core and=0A=
> built-in is not taking an effect. This way it'd be possible to add=0A=
> new ones in future PHP versions. Even more with `zend_ast_process`=0A=
> it'd be possible to implement core attributes which take effect on=0A=
> whole file in extension.=0A=
> =0A=
> I can imagine this can possibly be discussed to allow attributes for=0A=
> eg. from ctor to take effect on class but am not 100% sure of it is=0A=
> useful.=0A=
=0A=
Hi Micha=B3,=0A=
=0A=
I'm really not certain it's a good thing to have another way of adding=0A=
declares which would be ignored in older PHP versions. For instance,=0A=
in your example if the code is designed to work with stricter types,=0A=
what happens if it's unexpectedly run on an older version of PHP?=0A=
Instead of erroring as it should, the code might keep running but=0A=
produce unexpected results for certain inputs.=0A=
=0A=
> Going further with my imagination if we go that path with `#[Attribute]` =
=0A=
> we may think of adding error suppression.=0A=
> I know many don't like error-suppression but sometimes it's helpfull.=0A=
>=0A=
> In case of core attributes I can imagine a const value can be added=0A=
> renamed or removed, but the attribute remains the same then adding=0A=
> error suppression in a future allows to avoid crashing like for eg.=0A=
> =0A=
>     #@[Jit(Jit::OPTIMISE_SOMETHING)] // where the const may exists or not=
, but the Jit attribute does=0A=
>     function foo () {}=0A=
> =0A=
> In those cases we don't wanna crash the program, we may want it to=0A=
> continue rather without proper optimisation then not at all.=0A=
> =0A=
> I just see another use of current error-suppression operator @ to=0A=
> play nice with attributes.=0A=
=0A=
Please, let's not add a new place where error suppression can be used.=0A=
Yes, it's necessary when wrapping some old APIs that otherwise output=0A=
warnings, but for new APIs I really don't think this is a good idea.=0A=
=0A=
Best regards,  =0A=
Theodore=