On Thu, Jul 16, 2020 at 3:00 PM Theodore Brown <theodor...@outlook.com>
wrote:
> On Thu, July 16 2020 at 3:04 AM Nikita Popov <nikita....@gmail.com> wrote:
>
> > While I don't think anyone had plans to mix whitespace, this is
> > indicative of a larger issue. While I'm one of the people who voted
> > for @@ as my first choice before, I wouldn't do so now (even with
> > this RFC accepted). This issue made me realize that there is more at
> > stake here than just "which syntax is prettier?" and choices that
> > have a "closing tag" are technically more favorable, especially if
> > we consider future extensions of the attribute system that may
> > introduce additional ambiguities (e.g., Rust allows placing
> > attributes pretty much everywhere in code -- how sure are we that
> > there will be no unanticipated ambiguities?)
>
> Hi Nikita,
>
> Can you think of an example that would cause an ambiguity even when
> namespaced names are treated as tokens? As I understand it, there
> can't be an ambiguity, since there would always be an attribute token
> followed by a class name token. It should be possible to put this
> anywhere it makes sense without ambiguities.
>
Yes, there should not be any ambiguities at present. This is more of a
vague unease when it comes to future language extensions. To give an
example: Let's say that in the future, we allow annotations on statements,
and introduce generics using the ClassName{T} syntax (it's unlikely we'd
actually do that, even though this is the "least ambiguous" generics
syntax). Now, if attributes are just classes, it would stand to reason that
you can use something like @@OfType{int} as an attribute. If we combine
these two language changes, we get
@@FooBar
{
SomethingComplexHere
}
where SomethignComplexHere could be interpreted both as a type or an
expression. This does not cause a "true" ambiguity, but it does add an
infinite lookahead parser requirement, because we will only know how to
interpret this at the }. It could be an attribute with a generic parameter,
or it could be a non-generic attribute on a code block.
Of course, it is more likely than not, that we will not encounter any
issues of that nature.
Nikita
