On 7/31/19 10:22 PM, Nicholas Rosbrook wrote:
>> I looked at the thing about naked returns, and didn't really understand
>> it; but anyway I'm happy to have things modified to be more Go-like. I
>> definitely "speak" Go with a funny accent.
>
> TL;DR: Naked returns exist; don't use them (with the exception of defer'd
> closures if necessary).
Right, but that advice never made sense to me. The main reason
deprecating them in the document you pointed to is that they cause
"GoDoc stuttering"; and that having an extra "allocation" line in your
function is worth it to make documentation clearer. I agree with the
principle that clear documentation is important; but I wasn't clear what
the "stutter" looked like and why it was so bad.
The other reason listed is that you can accidentally mask your return
values; e.g. the following will return nil if Bar() returns an error,
which is probably not what the author intended:
func Foo() (err error) {
if err := Bar(), err != nil {
return;
}
...
}
While the following avoids that issue:
func Foo() (error) {
if err := Bar(), err != nil {
return err;
}
...
}
Normally I'm all for coding disciplines which add safety, but for some
reason this argument always seemed really weak to me. I really like
naked returns as a feature, and would rather just be more careful to
avoid masking.
Anyway, I wouldn't necessarily nack a patch getting rid of naked returns
(particularly if a second person wanted it), but I'm not very keen.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
