Well, FWIW, I'm not a fan of sigils either though, in this particular case,
it did seem to me to be a convenient way of solving a thorny problem given
that* ! *wouldn't be needed much anyway.
So what would you suggest then?
I think Ian's suggestion would work but, as a general approach, seems
rather drastic.
A pseudo-import would also work but to retain any granularity you might end
up needing a long list of these as the years go by.
Both the above are also 'take it or leave it' approaches. Either you can
use the new keywords as such or you can use them as ordinary identifiers -
you can't do both in the same package which my suggestion would allow.
Alan
On Saturday, October 27, 2018 at 3:49:24 AM UTC+1, kortschak wrote:
>
> Please no. The absence of sigils in Go is one of the syntactic features
> of the language that make it light to read.
>
> I don't want a symbol that, even if only due to external cultural
> context, suggests that the code is trying to say something exciting.
>
> On Fri, 2018-10-26 at 03:22 -0700, alan...@gmail.com <javascript:> wrote:
> > Inspired to some extent by Ian's idea, I've had another idea which
> > could
> > rid us of the *new keyword problem* not just for Go 1.xx or Go 2 but
> > for
> > ever. We wouldn't even have to worry about whether a new keyword
> > could be
> > restricted to *contextual* use or not.
> >
> > Suppose any new keyword introduced from Go 1.xx onwards could only
> > begin
> > with a lower case letter and could *optionally* be followed by the
> > *!*
> > symbol for disambiguation purposes. So, one could potentially have
> > check!,
> > handle!, contract! and so on.
> >
> > Suppose further that:
> >
> > 1. If you didn't use *!* and there was some local entity in an
> > *encompassing
> > scope* with the same name as the keyword, the compiler flagged it as
> > an
> > error.
> >
> > 2. If you did use *!* unnecessarily, the compiler would also flag
> > that as
> > an error.
> >
> > Now in the first case, you'd have the choice of either changing the
> > name of
> > the local entity to a non-keyword or adding *!* to the keyword
> > usage(s). In
> > practice, most people would probably choose the former.
> >
> > In the second case, you'd simply remove the *!* and that would be the
> > end
> > of the matter.
> >
> > Technically, an *encompassing scope* would be any scope which was or
> > included the scope in which the new keyword were being used. It
> > would
> > therefore always include package scope as a minimum.
> >
> > The advantages of this approach would be:
> >
> > 1. *!* would probably be seldom needed and so shouldn't impact too
> > adversely on the *look* of the code. Over time, people might simply
> > learn
> > to avoid using the new keywords as normal identifiers at least at top
> > level
> > within the package.
> >
> > 2. Existing code or new code using the *old* approach would continue
> > to
> > compile without problem.
> >
> > 3. Any function or method which didn't use any new keywords as such
> > could
> > still freely use them as identifiers for parameters, local variables
> > or
> > local constants. Disambiguation (or the lack of it) with similarly
> > named
> > top level entities (including new keywords) would be the same as it
> > is
> > today - the latter would simply be hidden.
> >
> > 4. Basically, you could just program normally (without *!*) knowing
> > that
> > the compiler would flag up any clashes.
> >
> > 5. Clashes with imported names would never be a problem because
> > they'd
> > usually be qualified by their package name and would begin with an
> > upper
> > case letter anyway.
> >
> > Although other symbols such as $, %, @ or ? could be used in place
> > of* !*,
> > I think the latter is probably the best choice as (to me at least) it
> > looks
> > less intrusive than the others and doesn't have any other
> > connotation. It's
> > also used (for different disambiguation purposes) in other modern
> > languages
> > such as Rust and Swift.
> >
> > As far as the generics proposal is concerned, the use of the
> > contract
> > keyword (which always appears at top level within the package) would
> > only
> > be flagged as ambiguous if there were another similarly named top
> > level
> > entity. Any use of *contract* within a function or method would not
> > be a
> > problem because of #3 above
> >
> > So what do you think, a viable idea or not?
> >
> > 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.
