My Favorite Go 2 Proposals

Nice little collection you've got there. I agree that the casing issues should be fixed, although this shouldn't be a high priority since you can always set up your editor to auto-complete this stuff for you.

I'm meh about interface literals to be honest. Making the sorter a separate type makes it more re-usable in my opinion.

The collect statement is sort of try-catch again, isn't it? The problem with these kind of catch-all statements is that developers end up writing hundreds of lines of code in the block, and then you are left wondering about where exactly the error was encountered (especially when using error tracking software such as Rollbar or Sentry)

Then, each time we assign to _!, it assigns that value to err, and checks if err != nil. If the assigned value is not nil, it exits the collect statement, and then the error handling can be done afterward.

...
...
...

congratulations, you just invented try-catch, which is a goto in disguise. truly everything new is old )

when I was inspired by golang (and node I guess)and wanted to do go-like error handling in php, I proposed to add conventional first argument, passed by reference to accumulate errors

after few functions called one can check if any errors occured and then decide what to return from calling function (maybe propagate errors further up the stack)

it was, of course, more of experiment than a complete solution, but it gave an alternative view on exceptions. Exceptions are gotos:
if first function in try block throws, you magically avoid calling second function which is, very likely, acceps value returned by first one as input. So exceptions are making your code obscure and extremely hard to understand. Actually, control on what happens in calling function is now in called function - just throw there and you force client code to obey and go to catch block, even though client code might wanted to do some more calls. Oh you really want to make sure you do that? Welcome to try-with-resources and finally and all sort of even more obscure stuff )

Instead it would be logical to admit that every time you call a function that would otherwise throw, you should really check error returned from this function and then branch your control flow with if statement - this way calling function is back in charge of what is going on. As a result code will look ugly in most of the languages. How to solve this - Im not sure yet, Optionals in java seems to be my next wearpon of choice - most of methods I write are now a chain of Optional.ifPresentOrElse() calls. Pretty declarative, I like to think of myself as a developer who uses functional style, who doesnt?))

Im still in search for THE solution (Im looking at you, monads), but my point here - question everything until you got to the core. Dont run around in circles.

Your code reminded me of my old library, mustbe. With mustbe, the code looks like this:

func SomeBigFunctionWithCollect() (i int, err error) {
  defer mustbe.Catched(func(e error) {
    fmt.Println("Error in SomeBigFunction:", e)
    err = e
  })

  mustbe.OK(SomeErrorProneFunction())
  mustbe.OKVal(AnotherFunc())
  // ...

  i = mustbe.OKVal(LastFunc()).(int)

  return
}

It's a bit more verbose, but it works already in Go1. Under the hood it uses panics, of course.

I'm a fan of fixing the casing issues, but not too big of a fan of the other two. Mainly because it feels like those two proposals add syntactic sugar in order to achieve brevity. I do believe verbosity is one of the reasons I like Go so much. You spend most of the day thinking, not writing code. Making it easier to read and understand is a plus for me. Having more constructs does add to more confusion while reading IMHO.

Not a fan of the collect statement either.

The point of handling different errors is that you often have to do different things based upon where the code errors.

Bundling them into a single return delegates the responsibility (and understanding) to somewhere or someone else

Something I might want to add:

proposal: Go 2: add become statement to support tail calls #22624

Tail calls allow for much faster recursion at the cost of reduced debug-ability. Might make a second post with some others that I may have missed! (Generics, other error handling solutions, etc)

I like that syntax, although my main issue is how it would treat multiple select statements. I had mentioned using err! instead of err. Maybe even err^ since it's moving "up" to the collect statement. Syntax isn't a huge issue and can always be figured out after semantics though :)

More consistency in the stdlib will be very welcome, but really this is not per se Go 2.

I don't like the collect. Right now, using a special function, you can handle all error cases except for when you need to break out of a block or function. A label, which nobody uses, could be used in a closure to skip to the end, but it is ugly. If there was a function to jump back two steps in the stack rather than just one and you have your tidy, structured and most importantly, short error handler. Collect doesn't even address this and if you didn't know you can make one line error handlers already except that trigger a break... A collect statement is far less obvious than breakon(err) or so, and a full handler function can also be written, and it could be completely up to you how to handle it.

Personally, apart from mandatory system specific, 'difficult' to write from scratch algorithms, I often don't even use stdlib that much.

If there was one thing I would like, that would be the option of curly blocks or whitespace delimited a la python. Just look at a typical function in Go. The opening parenthesis distracts (from human scripts we more usually use a : to head a subsection, like Modula and Oberon and go switches)... And then gofmt leaves the closure parenthesis on an otherwise empty line. Gofmt almost already forces the correct indentation anyway (it only allows open and close parentheses on closures very short if blocks).

Other than that, I would like a more concise but unambiguous closure, though on a github issue I posted, someone pointed out the increased ambiguity.

Personally, I will be disappointed if any changes that make the version two are not profoundly powerful, like for statements and strict static typing and interfaces combined.

I like the idea of collect, but the readability takes a nose-dive with that weird underscore syntax; I like the idea of err!.

Oh yeah, that's way better.

Nice.

That said, I don't love the added syntax of #2. I proposed a simplified alternative here though:

github.com/golang/go/issues/25626#...