8 ms·
I am strongly against this. `try` seems exactly like a function yet it is not acting like a function at all. People wouldn't expecting calling a function may re
by umurgdk 7y ago
I am strongly against this. `try` seems exactly like a function yet it is not acting like a function at all. People wouldn't expecting calling a function may return from the caller. And there is a reason why golang doesn't have macros. With macros all kind of craziness would be possible, and would really difficult to read different kind of projects' code.
- pjmlp 7y agoGo kind of has macros, like everything else, Go's solution to first level features in other languages is called //go:generate.
- lifty 7y agoI dislike this proposal for the same reason. Looks like a function but does not behave like a normal one. I personally don't mind the verbose error handling in go and I think it's clear and easy to follow.
- gnud 7y agoAgreed - I thought this looked pretty reasonable, if a bit parenthesis-heavy, until I saw this example: func printSum(a, b string) error { fmt.Println( "result:", try(strconv.Atoi(a)) + try(strconv.Atoi(b)), ) return nil } When you nest the calls to try inside another method call, like this, the control flow really becomes obscured.
- thisgoodlife 7y agoDo you think it would be better if it was called try_or_return?
- 0815test 7y ago> People wouldn't expecting calling a function may return from the caller. Why? This is essentially the same as the reset/shift pattern in e.g. Scheme - when you call shift from within a reset call, that might cause you to return directly from that. And that is a rather well-behaved pattern which composes quite well, it's nothing like the inherent weirdness of, e.g. call/cc.