I don't think we'll see check in the next draft. A LOT of the feedback[1] suggests various ways to invoke a named handler. But these are awkward: check(name) f(a) check(name, f(a)) f(a) check name
I hope check will be supplanted[2] by *symbol handler_name*, e.g. ?name = f(a); x(f?name(a)) #name = f(a); x(f#name(a)) @name = f(a); x(f@name(a)) [1] https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback [2] https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a On Wednesday, October 24, 2018 at 8:38:35 AM UTC-7, alan...@gmail.com wrote: > > 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> 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.
