News for hackers. Stuff that matters.
Re:Proposal: A built-in Go error check function, try by ngrilly on Wednesday June 05, 2019 @03:54AM (#20102340)
1. As explained in the proposal, try is not a keyword, but a built-in function.

2. Returning if there is an error is the whole point of this proposal.

3. I don't understand your point. Could you provide an example?

4. try is explicit. There is no implicit behavior or stack unwinding.

Re:Proposal: A built-in Go error check function, try by uryga on Wednesday June 05, 2019 @10:13AM (#20104539)
it uses the same syntax as functions, but it doesn't behave like a function – functions generally can't manipulate control flow like that. so calling it a function is weird because it's closer to a language construct like `await`
Re:Proposal: A built-in Go error check function, try by ngrilly on Wednesday June 05, 2019 @10:47AM (#20104934)
We already have one built-in function that alters the control flow: panic. But I agree it's a bit weird.
Re:Proposal: A built-in Go error check function, try by uryga on Wednesday June 05, 2019 @06:32PM (#20109805)
tbh i don't know Go too well. as i understand it, `panic` can indeed hijack the control flow, i.e. stop it. but any function¹ can do that: just do `while 1 {}`! control flow won't return to the caller either way. so it's not that weird after all

Ruby blocks can do non-local control flow, i.e. return from their surrounding function, but that's what makes them distinct from functions.

---

¹ in a turing-complete language

(i'm a Haskell enthusiast, so please excuse the nitpicking :)

Re:Proposal: A built-in Go error check function, try by ngrilly on Thursday June 06, 2019 @04:30AM (#20112632)
A panic can be recovered with recover(), and thus the program can continue. While a function that does an infinite loop will halt the program and nothing else.