On Monday, 26 January 2015 at 22:04:48 UTC, Zach the Mystic wrote:
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.
Copy/Paste:
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.
The return type doesn't appear after the function signature.
