> On Jul 28, 2020, at 14:10, Paul M. Jones <pmjo...@pmjones.io> wrote: > >> On Jul 28, 2020, at 14:07, Ben Ramsey <b...@benramsey.com> wrote: >> >>> On Jul 28, 2020, at 13:55, Paul M. Jones <pmjo...@pmjones.io> wrote: >>> >>> Now, it may be that #[] or <<>> or something else actually is "better" in >>> some sense that cannot be articulated. But if there are no existing >>> technical hurdles to be overcome with the already-voted-on-and-accepted >>> solution of @@, what technically compelling reason can there be to revote? >> >> >> IMO, there is no compelling reason to revote other than the fact that we >> have no process for what to do in this situation. > > What "situation" is this, exactly? AFICT we have a working implementation > using @@, with no technical hurdles to surmount. Or have I missed something > that now prevents @@ from working per its RFC?
The new RFC outlines reasons why `@@` is a sub-optimal choice. TL;DR: * current parser conflict (which can be worked around) * possibility for further (as of yet unknown) parsing issues * a closing ] makes it easier to extend Attributes with more syntax, and at the same time not be at the risk of running into parser conflicts * userland analysis tools have difficulties parsing `@@` Cheers, Ben
signature.asc
Description: Message signed with OpenPGP
