I quite like the draft error handling design and haven't (so far) suggested
that any changes be made.
However, one aspect I don't like is 'check' and 'handle' having to be
keywords which means that the design is not Go 1 compatible. Also, whilst I
agree that these words are probably the best ones for the job (and I would
hate to see them replaced by obscure symbols) it seems a pity that such
commonly used words will no longer be available as ordinary identifiers.
So all I'm asking here is whether - *if the design were adopted as it
stands* - they could be 'contextual' rather than 'full' keywords? I
couldn't find any mention of this in the draft papers but apologize in
advance if it's been addressed and I've missed it.
As far as this thread is concerned, I'm only interested in this question
and not what people think of the design generally.
It seems to me that they probably could be 'contextual' keywords i.e. they
could still be used as ordinary identifiers in the same package or even
within the same function (though the latter wouldn't be a great idea from a
readability perspective).
Considering first 'handle' which must be the first word in a line and then
be followed by an identifier. It cannot be any of the following:
1. A function call because its not followed by (.
2. An assignment because it's not followed by an =, := or , token.
3. An indexation expression because it's not followed by [.
4. A struct literal because it's not (directly) followed by {.
5. Any other expression because it's not followed by an operator.
So can anyone think of anything else it could be?
However, 'check' is more awkward because it's followed by an expression
(not an identifier) and need not be the first word in the line. If the
expression were bracketed or preceded by a unary operator then there would
be a potential ambiguity with #1 or #5 respectively.
So would it suffice for the compiler to try and interpret 'check' in these
situations as a 'normal' identifier and issue an error if it couldn't but
otherwise to interpret it as a error handling keyword?
The error would of course be easy enough to fix but, even if there are no
other ambiguities, would it just be too confusing and should we simply
accept that 'check' has to be a 'full' keyword as the design stands?
Alan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
