Go is still not good

>>ustad+(OP)
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?

>>gwd+ge
> 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.

>>thomas+Qm
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).

zlacker