On 1/28/2015 1:46 PM, Jonathan Marler wrote:
Your examples do bring up a usage I hadn't thought of though. It would be a bit
odd for newcomers to use "safe" without an '@' in one case and then have to
include the '@' another case (the example you provided). This makes it less
appealing. Either way, I don't think it matters since the proposal isn't
acceptable for a different reason, the leadership doesn't like the same words to
be used as function attributes sometimes and identifiers other times.
Good language design has redundancy in it. Often people see the redundancy, and
advocate removing it as noise. But the redundancy has a valuable purpose -
diagnosing of errors, and offering suggestions for fixing the errors. If there
was no redundancy in the language, every random sequence of bytes would be a
valid program.
For example, people often realize that the ; statement terminator is redundant,
so they propose removing it. In trying it, however, it soon becomes clear that
error message clarity, recovery, and the correct identification of the location
of the error degrades substantially.
So consider:
void func()
safe T = 7;
With your proposal, an error isn't discovered until the '=' is found. But what
kind of error is it? Did the user mean:
void func() safe;
void func() safe T;
void func(); safe T = 7;
Even for humans it can be hard to discern what the user meant it to be,
especially if he also is not using whitespace formatting as further redundancy.
Keywords and punctuation form "anchors" that both humans, syntax highlighters,
and parsers use to add redundancy and "synchronization points" (which enable
error recovery, such as "give up on the current AST and scan forward to find the
next anchor and start afresh").