As sad as it sounds, inside of me I agree on "it is all moot anyway",
but... Aren't we allowed to at least freely day-dream anyway :) ?
I was thinking about it over weekend, and came with these "rules", but I
need help on these for sure
1. If expression ends with ? (like func()?) , then it works as return in
"if a, err := func(); err != nil { return a, err }"
2. If it is in the middle of expression ...
1. without error handled
val := func()?.somethingElse().member
then it just expanded to a
val := (type(member))nil
if tmp, err := func(); tmp == nil || err != nil {
val = tmp.somethingElse().member
}
just saving the embarrassment of nil pointer dereference.
2. with an error on the left side
val, err := func()?.somethingElse()
then it is expanded to
val := (type(somethingElse())nil
var err error
if tmp, err := func(); if err == nil && tmp != nil {
val, err = tmp.somethingElse()
}
3. If error manipulation required - use a regular "if err != nil {
return _, wrap(err, "bad thing happen") }
I am probably overthinking it at this point (and it is way past bedtime),
but maybe it might make sense to have 2 different constructs - one for
nil-guard "?" and one for "check for nil AND error", thus becoming "??"
With that logic above, the following should make some sense
type Mood interface {
frolic()
avoided() Mood
passed() (Mood, error)
}
func getMood() (Mood, error) {...}
func usage1() (Mood, error) {
return getMood()??.passed()
}
func usage2() error {
return getMood()??.passed()
}
func usage3() interface{} {
return getMood()?.avoided()
}
func usage4() (interface{}, error) {
mood := getMood()?? /// will short-circuit if getMood() returns an
error
return mood?.passed() // guard for mood == nil; but will return no
error in that case either since it will be nil
}
Andrey
On Tuesday, July 2, 2019 at 12:10:20 AM UTC-6, Liam wrote:
>
> 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 <xnow4f...@sneakemail.com
> <javascript:>> 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
>> golan...@googlegroups.com <javascript:>.
>> 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/b6257202-4a4e-4dd8-ab8b-7fcbfaf448d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
