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.f...@gmail.com 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.
