On Saturday, 8 February 2020 10:33:03 UTC, addi t0t08 wrote:
>
> No, 'pass' accepts an error type. in this case Foo function must return an
> error type otherwise that would be a compile error.
>
>
Ah I see: you are relying on the behaviour of errors.Wrap(nil, "dontcare"),
which is valid and returns nil. That's a bit of hidden magic.
> I already said, multiple return values are supported (the original
> proposal also handles this) otherwise what's the point?. You can do this:
>
>
> func doSomeTask() (int, bool, error) {
> f, err := os.Open(filename)
> pass err
> defer f.Close()
>
> ....
> return 10, true, nil
>
> }
>
>
For me, looking at this code I ask:
- What would "pass" return for the int and bool arguments - the zero value
for each perhaps?
- What would it do instead if these were named return values? Would it
return the values already assigned, or always zero values?
To me, this seems to be hidden magic, when compared with the original if
statement, which has absolutely unambiguous semantics.
Aside: I suppose it's worth mentioning that in principle golang lets you do
this:
if f, err := os.Open(filename); err != nil {
return 0, false, SomeError
}
However, this form isn't as useful as it first appears, because "f" drops
out of scope after the "if" statement. You can put the rest of your code
inside an "else" block; or you can pre-declare your variables before the
"if" statement. Either way is more work than it saves.
var f, g *os.File
var err error
if f, err = os.Open(file1); err != nil {
return 0, false, SomeError
}
defer f.Close()
if g, err = os.Open(file2); err != nil {
return 0, false, SomeError
}
defer g.Close()
... etc
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/f5ae28a4-a1ce-47b3-b580-9621967eb531%40googlegroups.com.
