Re: [RFC] Shorter Attribute Syntax Change RFC 0.2

Hi Benjamin,

## Easier machine parsing? The RFC shows a list of different ways that attributes with the @@ syntax can end, and claims "This makes programmatic token based scanning for attribute syntax without a closing delimiter such as @@ unnecessarily complicated." But I've worked with userland token stream scanners myself, and it's not difficult to skip T_WHITESPACE and T_COMMENT tokens. Once you do that, parsing an attribute is as simple as finding any T_ATTRIBUTE token followed by the name token, then checking for an optional argument list. If there's not an argument list, that's then end of the attribute, otherwise the end is the end of the argument list. With the @[] and #[] syntaxes, a userland token parser is actually *more* complex due to grouping. It not only has to do the same things listed above, but it also has to check whether there are multiple comma-separated attributes between the start/end delimiters (making sure not to confuse a comma-separated attribute with a comma-separated argument, or the end of an array argument with the attribute end delimiter). So I don't understand how the RFC can claim that attributes without an end symbol "introduce additional complexity" for machines, when if anything the opposite is true. (And don't get me started about the extra difficulty for token stream scanners with the <<>> syntax which has no T_ATTRIBUTE token).

I noticed you did not answer this point at all, I know there are lots of emails to reply to but IMO this is quite an important dismissal of one of the few technical arguments made for grouping, and also something I tried to hint at on Twitter back on Sunday.. Reading the RFC again now, IMO the whole "Machine Scanning for End of Attribute Declaration" section should be removed. From the points left, only "Potential Future Benefits of Enclosed Delimiter Syntax" is technically valid but really dependent on what we see as interesting future use cases. The rest is rather subjective and thus not really worth discussing, it'll be up to everyone's preference. Best, Jordi -- Jordi Boggiano @seldaek - https://seld.be