[go-nuts] Re: Proposal: return if any not nil
On Sunday, February 18, 2018 at 12:47:09 AM UTC-7, Krzysztof Kowalczyk
wrote:
>
> Even simpler:
>
> r, err := try os.Open("blah.text")
>
> Similar to Swift and what Rust used to have.
>
> "try foo()" means: if "foo()" returns an error, return the error to the
> caller.
> If function returns multiple values, it would return zero value for
> non-error values.
>
> I believe now Rust has the following syntax:
>
> r, err := os.Open("blah.text")?
>
> Either way, even less boilerplate.
>
Since the intention is to return on an error, it should only return if the
last return value is a pointer and non-nill, not if any value does not have
its zero value.
There are 8 suggestions under Error Handling in the Go Experience Reports.
This should be written up and posted there if it isn't already covered.
--
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.
[go-nuts] Re: Proposal: return if any not nil
Even simpler:
r, err := try os.Open("blah.text")
Similar to Swift and what Rust used to have.
"try foo()" means: if "foo()" returns an error, return the error to the
caller.
If function returns multiple values, it would return zero value for
non-error values.
I believe now Rust has the following syntax:
r, err := os.Open("blah.text")?
Either way, even less boilerplate.
--
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.
Re: [go-nuts] Re: Proposal: return if any not nil
I think for me the benefit of a new statement is that it doesn't result in
changes to existing formatting/behaviour. Rather it provides a familiar
syntax and style semantic and results in no change to an existing code base
(e.g. it's opt in).
The problems I see with allowing 1 liner conditionals are;
- it breaks the existing reader flow for exception cases (this proposal
does as well but in a narrower scope).
- it results in ambiguity around how gofmt should behave.
- it would result in arbitrary churn relating to reformatting for existing
code bases or worse lilliputian arguments over code formatting if flags
were used.
I like the relatively consistent and unambiguous output that gofmt is able
to achieve.
If this new statement were used exclusively for error handling I could see
it testing for nil in the position of an error interface argument. Which
would essentially make it a macro that expands to the existing conditional
formatting with the same overhead as the multi-line conditional return
where;
func () (*Foo, error) {
...
retnnerr nil, err
would effectively expand to the same representation as;
... // retnnerr nil, err was here
if err != nil {
return nil, err
}
An alternative format could be to only specify the err variable as part of
the statement and then automatically apply the "default" value for all
other return params...
retnz err
I'm not sure I like that though because I think it is against Go's tendency
of being explicit in returns.
An issue I could see to both of the above is where multiple errors are
specified as a return value. I haven't seen that done in practise but
there's nothing in the language spec that prevents someone from writing an
API with that specification.
One way I could see addressing that with `retnnerr` is where constants and
blank/nil values are defined they would not be tested.
On Sat, 17 Feb 2018 at 09:14 Michael Jones wrote:
> The notion of "return X if Y" is fun...it means I'm waking up to SNOBOL in
> 2018. Fantastic flashback but awkward here.
>
> Changing formatting to allow single line "if X { trivial Y }" seems
> natural.
>
> On Sat, Feb 17, 2018 at 6:05 AM, wrote:
>
>> The OP's idea is the best one so far. What about the following.
>>
>> r, err := os.Open("blah.txt")
>> *return* nil *if* r == nil, err *if* err != nil
>>
>> basically every return field could be followed by an optional if clause
>> with an expression that must evaluate to bool.
>>
>> The return only happens if all optional if clauses evaluate to true.
>>
>> Could be also used to bubble errors up the stack
>>
>> r, err := os.Open("blah.txt")
>> *return* nil, fmt.Errorf("File open failed") *if* err != nil
>>
>>
>>
>> --
>> 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.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> 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.
>
--
- sent from my mobile
--
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.
Re: [go-nuts] Re: Proposal: return if any not nil
The notion of "return X if Y" is fun...it means I'm waking up to SNOBOL in
2018. Fantastic flashback but awkward here.
Changing formatting to allow single line "if X { trivial Y }" seems natural.
On Sat, Feb 17, 2018 at 6:05 AM, wrote:
> The OP's idea is the best one so far. What about the following.
>
> r, err := os.Open("blah.txt")
> *return* nil *if* r == nil, err *if* err != nil
>
> basically every return field could be followed by an optional if clause
> with an expression that must evaluate to bool.
>
> The return only happens if all optional if clauses evaluate to true.
>
> Could be also used to bubble errors up the stack
>
> r, err := os.Open("blah.txt")
> *return* nil, fmt.Errorf("File open failed") *if* err != nil
>
>
>
> --
> 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.
>
--
Michael T. Jones
michael.jo...@gmail.com
--
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.
[go-nuts] Re: Proposal: return if any not nil
The OP's idea is the best one so far. What about the following.
r, err := os.Open("blah.txt")
*return* nil *if* r == nil, err *if* err != nil
basically every return field could be followed by an optional if clause
with an expression that must evaluate to bool.
The return only happens if all optional if clauses evaluate to true.
Could be also used to bubble errors up the stack
r, err := os.Open("blah.txt")
*return* nil, fmt.Errorf("File open failed") *if* err != nil
--
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.
[go-nuts] Re: Proposal: return if any not nil
Or just change how gofmt formats if statements where the block is a single
return statement.
if r, err := os.Open( "blah.text"); err != nil { return nil, err }
Or if parseable:
return r, err if { r, err := os.Open( "blah.txt" ) ; err != nil }
I think the first is better, but I'm happy with Go as it is.
Jonathan
--
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.
[go-nuts] Re: Proposal: return if any not nil
Ah, I just re-read the thread subject: if *any* of the values are non-nil.
Sorry for the misunderstanding.
On Friday, February 16, 2018 at 3:42:23 PM UTC-7, Paul Brousseau wrote:
>
> If all of the values are non-nil, then `retnn nil, err` would not return,
> would it? Did I miss something?
>
> On Friday, February 16, 2018 at 2:38:05 PM UTC-7, Nathan Fisher wrote:
>>
>> Hi All,
>>
>> I've been contemplating alternative methods to address the "boiler plate"
>> of error handling in Go. One of the main benefits I see to the current
>> approach is that indentation highlights exception paths vs the success
>> path. From a readability perspective I can see the benefit of this
>> approach. It allows a reader to efficiently scan a function.
>>
>> One problem I see with the approach however is that it results in a lot
>> of vertical expansion in the code. If you take a fail-fast and return such
>> as the following it requires 4 lines of code for every check or worse
>> people ignore the error with an underscore.
>>
>> r, err := os.Open("blah.txt")
>> if err != nil {
>> return nil, err
>> }
>>
>> What I've been thinking about is a return statement that will return only
>> if all of the values are non-nil/blank.
>>
>> The statement would enable you to replace the above with a single return
>> as follows;
>>
>> r, err := os.Open("blah.text")
>> retnn nil, err
>>
>> I'm not wedded to the statement name retnn but more the general principle.
>>
>> Thoughts?
>>
>> Nathan
>>
>
--
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.
[go-nuts] Re: Proposal: return if any not nil
If all of the values are non-nil, then `retnn nil, err` would not return,
would it? Did I miss something?
On Friday, February 16, 2018 at 2:38:05 PM UTC-7, Nathan Fisher wrote:
>
> Hi All,
>
> I've been contemplating alternative methods to address the "boiler plate"
> of error handling in Go. One of the main benefits I see to the current
> approach is that indentation highlights exception paths vs the success
> path. From a readability perspective I can see the benefit of this
> approach. It allows a reader to efficiently scan a function.
>
> One problem I see with the approach however is that it results in a lot of
> vertical expansion in the code. If you take a fail-fast and return such as
> the following it requires 4 lines of code for every check or worse people
> ignore the error with an underscore.
>
> r, err := os.Open("blah.txt")
> if err != nil {
> return nil, err
> }
>
> What I've been thinking about is a return statement that will return only
> if all of the values are non-nil/blank.
>
> The statement would enable you to replace the above with a single return
> as follows;
>
> r, err := os.Open("blah.text")
> retnn nil, err
>
> I'm not wedded to the statement name retnn but more the general principle.
>
> Thoughts?
>
> Nathan
>
--
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.
