@Justin_Israel I cannot imagine, off the top of my head, a case when you will need to return multiple errors from one function, it either has an error or not.
You can create a method MustEnsurePermission (in lack of a better name) that calls EnsurePermission and, if there is an error, panics instead of returning the error. The panic can be recovered in your main handler that will return an 500 HTTP status, for example.
The idea is to use panic/recover to unwind the stack, without writing boilerplate code.
Here is an example recently shared on golang-nuts: http://play.golang.org/p/Kjt34Nev15
And here is an example in the standard library: https://golang.org/src/encoding/gob/error.go
Alright, Iâll give it a try.
It does absy nothing, just continues runtime flow as expected.
I canât imagine a single case with multi-error return and I havenât seen a single case like that. You can fall back to regular if matching then, though. Tilde isnât something that you must use, itâs just a sugar over countless trivial return err; cases, w/o any actual error handling.
Yeah, thatâs pretty much what I was talking about in context of main() and init(). You can spread the definition of tilde placeholder in a breeze: â⌠for err-returning functionsâ and you are also supposed to fall back to existing if matching otherwise. It makes perfect sense to me.
Using panic for this is a big no-no. Missing permission for API falls into âbad user inputâ category. You want normal âtreat errors as valuesâ handling here.
At one point, the Apache Thrift Go bindings generator was generating functions with multiple return errors, for services in the thrift definition that also declared that they throw an exception. This was to preserve the service exception type as one error and still communicate thrift-based errors as another (for better or for worse). The generator plugin has since been updated to consolidate this logic into a single error value. But my point is that I encountered it quite early in my experience, and furthermore regardless of best practice, the language allows it. So your magic error handling has a number of caveats.
Also, I am not really trying to make you qualify a proposal, since this is just your wish list. Moreso just suggesting possible reasons it didnât make it past previous similar discussions on golang-nuts. My guess is that convenience features that have magical qualities and caveats for their application seem to not make it very far in the proposals.
Ternary operator.
func Abs(n int) int {
return n < 0 ? -n : n
}
I know its lazy coding and could be less readable at times 
8 Likes
right! are there any reasons, why this is not implemented?
If you want to treat the âbad user inputâ error as a value, which is a perfectly valid approach, then the pattern if err != nil { return err } is perfectly ok, in my opinion. The caller will receive the error value and decide what to do about it. In my opinion, this approach is very repetitive when the caller doesnât know what to do with the error value, except returning it to its caller, etc., until you reach the main handler that will return a 400, 404 or 500. In such a case, you have a chain of if err != nil { return err } which are just a very repetitive and boring way to unwind the stack. This is the case where I think using panic/recover to unwind the stack and transfer the error value can be a better approach, which is even use in some places in the standard library.
1 Like
This. I love ternary operators, anyone with idea why this is not implemented? 
Ternary operator was mentioned in the Go FAQ but no reason was stated for its absence.
Ternary op is often misused, expressions are hard to read, etc.
1 Like
Anything in any language when used incorrectly can become a mess. 
Fair point. Still, Pike & Co. thinks otherwise 
1 Like
I also miss one liners. Functions with multiple return types destroys that for me 
I wish if thereâs a way to index return values.
Example âfatal errorâ and âmisc errorsâ: https://github.com/raintreeinc/knowledgebase/blob/master/ditaconv/converter.go#L14
The code converts DITA into an HTML, there can be errors and fatal error â i.e. in one case this conversion result shouldnât be used, in the other case there are some validation errors, but they either are minor or were automatically corrected (e.g. filename casing issues).
1 Like
Iâve got one thing, but itâs been discussed and I have a proposal on its way when I get a chance.
In the meantime, I love the go community. I just wish there was a more centralized place to DISCOVER packages. Iâm not saying a non-distributed import system (b/c I like the lack of dependencies on a central repository). However, I wish there was a common place that indexed all public Go packages and allowed comments, concerns, and +1s.
Itâs not really a language feature, but it would be nice.
The other criticism that someone brought up was the lack of versioning with packages. I think that these issues are easily solved by vendoring though
1 Like
I miss a better type inference in struct literals
type Foo struct {
X int
}
var f F = { X : 1 } // won't compile
type Bar struct {
F Foo
}
b := Bar {
F: { X : 1 }, // won't compile
}
var f func(Foo)
f({X:1}) // won't compile
Related to that, I miss arrow functions
var f func(int, int) int
f = (x, y) => x + y // won't compile
var g func(func(int) int)
g(x => x * 2) // won't compile
2 Likes
I donât buy the => syntax, I donât see why a special form of function literal declaration is required.
var f = func(x, y int) { return x + y } // more readable
var g func(func(int) int)
g(func(x int) int { return x * 2 }) // more readable
4 Likes
I think a full function type is unnecessary to specify because it can be inferred from the context. It is unnecessary for the same reason why we donât specify parameter type in f('a') for func f(byte). The value is enough