← Back to context

Comment by gwd

1 day 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?

6 comments

gwd

Reply
thomashabets2  1 day 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  1 day ago

    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  1 day ago

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  1 day ago

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

terminalbraid  1 day ago

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

  • gwd  1 day ago

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