Hmm, interesting idea!
Presumably, that would still work if 'check' were declared as a local
variable within the same function *after* all the error handling stuff, as
the compiler would detect it on first pass.
I wondered myself about having some sort of pragma or pseudo-import (say:
import . "E") at top level within the package to turn the new error
handling on but as that would be a new feature in itself perhaps it's not
such a good idea.
Alan
On Wednesday, October 24, 2018 at 3:22:03 PM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Oct 24, 2018 at 3:49 AM, alanfo <alan...@gmail.com <javascript:>>
> 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.
