Erm, what expression besides a function call would yield an error only sometimes? I suppose channel receive, but is that a useful case?
It's all moot anyway. On Mon, Jul 1, 2019, 10:42 PM Andrey Tcherepanov < xnow4fippy...@sneakemail.com> wrote: > Thanks Liam, > > your suggested placement would make it somehow impossible (or at least I > cannot see it right now) to use with someExpression?.someMember > If I am not mistaken, yours is close to the currently proposed "try", just > replacing it with ?, am I right on that ? > > A. > > On Monday, July 1, 2019 at 2:49:09 AM UTC-6, Liam wrote: >> >> I've noted in several places that a 'try' expression (via keyword, >> built-in, or symbol) is suitable only when the function is expected to >> always succeed, and so would panic on error. >> >> Also the symbol, which I agree is preferable, works best this way >> will?(always?(work?())) vs will(always(work()?)?)? >> >> On Saturday, June 29, 2019 at 4:05:44 PM UTC-7, Michael Jones wrote: >>> >>> My personal thought, though it may seem strange, is that the best >>> argument for it lies in the single word sentence at the bottom of your >>> email. You write "Thoughts?" -- and that is very expressive in English in >>> just the way that you mean above in your examples. I don't know enough >>> other languages to really know if the parallels are universal, but it's >>> pretty clear to me what it means why "file?.close()" and >>> "os.Open(filename)?" are "punctuated" as they are -- where the question is. >>> I feel like you're asking this compiler, "is there anything about this >>> value that you need to tell me?" I like that. >>> >>> The long (crazy long!) discussion of error handling has among its many >>> branches an analysis from the Go team about '?' and this kind of postfix >>> interrogation. I'm watching it all with a bit of wonder, but I wanted to >>> speak up and say how your human-language phrasing matches your idea of >>> computer-language phrasing. That seems a powerful kind of naturalness to >>> take advantage of in this issue and future ones. >>> >>> On Sat, Jun 29, 2019 at 2:56 PM Andrey Tcherepanov < >>> xnow4f...@sneakemail.com> wrote: >>> >>>> Hello mighty fighters of errors! >>>> >>>> Here comes my half-thought idea of another way to express error >>>> handling: >>>> >>>> *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND >>>> an error for nil. * >>>> >>>> (Denis have shred it to pieces already in >>>> https://github.com/golang/go/issues/32852. Thank you Denis.) >>>> >>>> I am not good with expressing my inner talk, so there are couple >>>> examples >>>> >>>> original , Go 1 function >>>> >>>> func stat(filename string) (os.FileInfo, error) { >>>> >>>> var info os.FileInfo >>>> { >>>> var a1 *os.File >>>> if a1, err := os.Open(filename); err != nil || a1 == nil { >>>> return _, err >>>> } >>>> var a2 os.FileInfo >>>> if a2, err := a1.Stat(); err != nil || a2 == nil { >>>> return _, err >>>> } >>>> info = a2 >>>> } >>>> return info, nil >>>> } >>>> >>>> >>>> And with "?", trying to avoid original try() proposal handle leak >>>> >>>> // would return _, err, but since there is no err in signature, will >>>> return default value in case of error >>>> // uses ? on func call that returns (value, error) >>>> func stat2(filename string) (os.FileInfo) { >>>> file := os.Open(filename)? >>>> defer file.Close() >>>> return file.Stat()? >>>> } >>>> // would return error too, uses ? as "not nil" on a variable too >>>> func stat3(filename string) (_ os.FileInfo, err error) { >>>> var file *os.File >>>> defer file?.Close() >>>> file := os.Open(filename)? >>>> return file.Stat() >>>> } >>>> >>>> >>>> Thoughts? >>>> >>>> -- >>>> 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 golan...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/b7520ffe-ec38-4157-8f95-92844dcb0d0f%40googlegroups.com >>>> <https://groups.google.com/d/msgid/golang-nuts/b7520ffe-ec38-4157-8f95-92844dcb0d0f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> >>> *Michael T. jonesmichae...@gmail.com* >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/-lmobOi3p5s/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/93987580-3f1d-4ab8-b796-2e095d49a3b4%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/93987580-3f1d-4ab8-b796-2e095d49a3b4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKvHMgT2fbqygn3L3aMvSZBM-TDrEs2uJiO5wjFKNQR9NXpZLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
