3 ms·
Anyone want to try to explain what he's on about with the first example? bar, err := foo() if err != nil { return err } if err := foo2();
by gwd 1y ago
Anyone want to try to explain what he's on about with the first example?
bar, err := foo()
if err != nil {
return err
}
if err := foo2(); err != nil {
return err
}
The above (which declares a new value of err scoped to the second if statement) should compile right? What is it that he's complaining about?
EDIT: OK, I think I understand; there's no easy way to have `bar` be function-scoped and `err` be if-scoped.
I mean, I'm with him on the interfaces. But the "append" thing just seems like ranting to me. In his example, `a` is a local variable; why would assigning a local variable be expected to change the value in the caller? Would you expect the following to work?
int func(a *MyStruct) {
a = &MyStruct{...}
}
If not why would you expect `a = apppend(a, ...)` to work?
- terminalbraid 1y agoYou didn't copy the code correctly from the first example.
- gwd 1y agoWell no, the second "if" statement is a red herring. Both of the following work: bar, err := foo() if err != nil { return err } if err = foo2(); err != nil { return err } and bar, err := foo() if err != nil { return err } if err := foo2(); err != nil { return err } He even says as much: > Even if we change that to :=, we’re left to wonder why err is in scope for (potentially) the rest of the function. Why? Is it read later? My initial reaction was: "The first `err` is function-scope because the programmer made it function-scope; he clearly knows you can make them local to the if, so what's he on about?` It was only when I tried to rewrite the code to make the first `err` if-scope that I realized the problem I guess he has: OK, how do you make both `err` variable if-scope while making `bar` function-scope? You'd have to do something like this: var bar MyType if lbar, err := foo(); err != nil { return err } else { bar = lbar } Which is a lot of cruft to add just to restrict the scope of `err`.
- sublimefire 1y agoedit: the main rant about err was that it is left in scope but I believe the author does not like that
- mrweasel 1y agoThat might be it, but I wondered about that one, as well as the append complaint. It seems like the author disagree with scoping rules, but they aren't really any different than a lot of other languages. If someone really doesn't like the reuse of err, there's no reason why they couldn't create separate variable, e.g. err_foo and err_foo2. There's not no reason to not reuse err.
- thomashabets2 1y ago> why would assigning a local variable be expected to change the value in the caller? I think you may need to re-read. My point is that it DOES change the value in the caller. (well, sometimes) That's the problem.
- gwd 1y agoOh, I see. I mean, yeah, the relationships between slices and arrays is somewhat subtle; but it buys you some power as well. I came to golang after decades of C, so I didn't have much trouble with the concept. I'm afraid I can only consider that a taste thing. EDIT: One thing I don't consider a taste thing is the lack of the equivalent of a "const *". The problem with the slice thing is that you can sort of sometimes change things but not really. It would be nice if you could be forced to pass either a pointer to a slice (such that you can actually allocate a new backing array and point to it), or a non-modifiable slice (such that you know the function isn't going to change the slice behind your back).