On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:
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
I think you meant someone else!
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).
I don't think it is possible. Any non-keyword identifier is
assumed to be the return type of the function. It all has to be
solved in the parsing phase. You can't wait till semantic
analysis to figure out what's a return type and what's an
attribute. This is why D compiles so fast, because all phases of
compilation are distinct.
