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?

▲ thomashabets2 4 days ago | parent | next [-]

> 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 3 days ago \| parent [-]
		Oh, 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).

▲ mrweasel 4 days ago | parent | prev | next [-]

That 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.

▲ sublimefire 4 days ago | parent | prev | next [-]

edit: the main rant about err was that it is left in scope but I believe the author does not like that

▲ terminalbraid 4 days ago | parent | prev [-]

You didn't copy the code correctly from the first example.

	▲	gwd 4 days ago \| parent [-]
		Well 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`.