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 <michael.jo...@gmail.com> 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, <charras...@gmail.com> 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.
