On Wed, Oct 24, 2018 at 3:49 AM, alanfo <alan.f...@gmail.com> wrote:
>
> 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?
I think that if a package does define `check` as a local function,
then making contextual choices about whether `check` in an expression
refers to the function or to the error checking behavior can only be
confusing.
One approach that could perhaps work--and I'm not at all endorsing
this, just pointing it out--is that if a package defines `check` as a
local name of any sort, the compiler could simply disable the error
checking behavior of `check`. That is, `check` would only be a
keyword if there were no local definition of `check`.
Ian
--
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.
