[wybiral]

> Because it encourages nesting function calls, which is harder for a human to parse than separate statements across lines.

I absolutely agree. Beyond the human parsing aspect it also makes commit changes easier to reason about and review. I want functionality to be limited per-line and view the ability to combine a lot of functionality into one line as a liability more than a benefit.

Go's error handling isn't carefree or hands-off, but that's because error handling is serious. Especially in network code and cryptography.

[gigatexal]

I thought it could lead to doing method chaining for a fluent like API which I find cleaner than how things work now.

[natefinch]

I really dislike method chaining. I'd much rather have 5 lines than 5 chained methods. If that's too much to read, you can always encapsulate it in a well-named function.

[gigatexal]

But five functions that return a value and an error would each have to run the if err != nil dance whereas with method chaining it's cleaner

[NateDad]

not if each one can fail. What if call #1 and call #3 can return the same error.. how does the caller know which one failed? This is the same as wrapping a bunch of calls with a catch (Exception) ... you lose context of what failed and can't behave differently for different failures. All you can do is perform a generic "something went wrong" behavior.

[mikeschinkel]

Interestingly you _can_ implement method chaining to require a terminal method call i.e. err := GetFoo().SetBar(1).SetBaz(2).Run() and then each chained method would set an error property in the object and if err!=nil then do nothing but return the object, and then the last method could return the error value.

That said, I am not a huge fan of fluent interfaces. I much prefer passing in a struct as an "args" parameter, in most case (but not all.)

[saturn_vk]

That can easily be done right now with the current way of error handling.

[gigatexal]

Do you have any examples?