Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-11 Thread Wojciech S. Czarnecki
Dnia 2020-11-11, o godz. 08:01:37 Jeremy French napisał(a): > I know that's not realistic, and errors are a part of life. > My point is that they're not the main purpose of the code, and thus shouldn't > be taking up (up to) 75% of the code space when I'm trying to read what a > function does.

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-11 Thread 'Axel Wagner' via golang-nuts
On Wed, Nov 11, 2020 at 5:02 PM Jeremy French wrote: > *shrug* As you said, returnif is still a statement, and yet it reduces the > minimum boilerplate from 3 lines down to 1. > There's a way to get that without a language change - you can have gofmt make `if err != nil { return … }` into a 1-li

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-11 Thread Jeremy French
On Wednesday, November 11, 2020 at 2:09:19 AM UTC-5 axel.wa...@googlemail.com wrote: > On Wed, Nov 11, 2020 at 2:43 AM Jeremy French wrote: > >> I certainly can't speak for the whole community, but for me, the key word >> here is verbosity. I don't care (too much) whether it's technically a

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-10 Thread 'Axel Wagner' via golang-nuts
On Wed, Nov 11, 2020 at 2:43 AM Jeremy French wrote: > I certainly can't speak for the whole community, but for me, the key word > here is verbosity. I don't care (too much) whether it's technically a > statement or an expression or a macro. What I care about is signal to noise > ratio in my cod

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-10 Thread Jeremy French
On Tuesday, November 10, 2020 at 6:12:18 PM UTC-5 axel.wa...@googlemail.com wrote: > IMO, `returnif , ` reads awkwardly. If anything, it should > really be `return if `. At which point it also becomes > clear that this isn't actually much of an improvement over `if { > return }`. > "retu

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-10 Thread 'Axel Wagner' via golang-nuts
IMO, `returnif , ` reads awkwardly. If anything, it should really be `return if `. At which point it also becomes clear that this isn't actually much of an improvement over `if { return }`. On Tue, Nov 10, 2020 at 11:59 PM Tyler Compton wrote: > The "try proposal" and some others identified a

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-10 Thread Tyler Compton
Some thoughts: The "try proposal" and some others identified and solved two problems: a. The verbosity of using a full if statement to check error values b. The verbosity of applying wrapping and other error handling logic to every place where an error is returned This proposal only addresses Pr

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-09 Thread Jeremy French
Hm, yep. Very similar. Interestingly, the only cohesive objections I can see in those threads are to the minor details that are different from what I'm saying. Still, though - at least the idea has been presented before. Jeremy French 607-444-1725 On Mon, Nov 9, 2020, 2:57 PM Ian Lance Taylor wr

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-09 Thread Ian Lance Taylor
On Mon, Nov 9, 2020 at 11:20 AM Jeremy French wrote: > > First, the caveat. I know error handling is a long-standing discussion. I > know there has been lots of debate on error handling, and it can seem like > there are no more new ideas to be had on the topic. And I have looked at > several

[go-nuts] Proposal: New keyword returnif (resolves error handling)

2020-11-09 Thread Jeremy French
First, the caveat. I know error handling is a long-standing discussion. I know there has been lots of debate on error handling, and it can seem like there are no more new ideas to be had on the topic. And I have looked at several/most of the most popular proposals, and there are quite a few t