On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler
wrote:
I agree with Jonathan's points, this solution doesn't seem
like an improvement. If I understand the problem, we don't
want to make every attribute use the '@' symbol because it
looks bad and would cause a lot of code changes for sake of
consistency. However, on the other hand, we don't want to
support the new properties because we have to add them as
keywords which would break code using those words and would
make the language more restrictive (nothing can be named
nogc/safe/...).
Assuming I understand the problem, couldn't we modify the
language grammar to support more attributes without making
them keywords? Then we can omit the '@' on future code (and
fix the old code if we want) and we don't have to litter the
language with new keywords.
I understand that doing this may be fairly complicated. This
may create some ambiguities in the grammar that would need to
be handled carefully, but if it can work I think this would be
a good option.
I think the short answer is that it's WAY too complicated for
the benefit. Also, why burden the syntax highlighter, let alone
the human reader, with ambiguities like this?
I wasn't saying that we should introduce ambiguity, I was saying
we should be careful not to introduce ambiguity. I wrote that to
indicate that I wasn't sure if the solution would introduce
ambiguity or not. Zach suggested a solution that I'm fairly
certain would be unambiguous (it's nice to have c++ people who've
already seen the same problem know of a solution). By
restricting the attributes to only appear after a function
signature, it would also normalize the issue of consistent
location of attributes, but this is another debate. However,
allowing the attributes to appear before the function signature
*might* work, but that would require much more care and may not
even be possible (like I said, I'm not sure). A comprimize could
be to allow attributes to omit the '@' character if they appear
after the function signature and require the '@' character if
they appear before. I'm not saying that's a good idea, just an
option.
