3 ms·

What's the benefit of the result type here, instead of keeping the "error" in the last spot? This would require refactoring everything, leaving you with "old st

What's the benefit of the result type here, instead of keeping the "error" in the last spot? This would require refactoring everything, leaving you with "old style" and "new style" APIs. Couldn't "?" just mean "strip the error", i.e. act as if the function only returns the value(s) it returns, and if the "?" "triggers", it would just return default/empty values for all parameters + the error in the error field. This also allows seamlessly mixing the abbreviated version and the full current approach if you need it for some reason. I honestly also don't see how retrofitting it wouldn't be trivial. One could probably even write a preprocessor for that. The most common argument I've heard is that it will lead to less explicit error messages because people will just pass through the original error instead of f, err := os.Open(savegamepath) if (err != nil) { return nil, fmt.Errorf("Couldn't load savegame: %s", err) } so providing some convenient way to add this information would be great. Especially if it could be added once per function, and the whole system would preserve the stack trace like exceptions in any sane language do. Just adding the stack trace alone will make the additional context a lot less important. I'd rather have human-written context and the stacktrace, but if I can have only one, I'd rather take the stack trace, especially since humans will be lazy and often omit the context.

topspin 4y ago
> What's the benefit of the result type here Only to be consistent with the more general case: func tryToGetSomething() Result<Something> {...} Or perhaps you mean why not: func CopyFile() Result<error> {...} Yeah, sure. I don't care. I'm just tired of typing and wading through if (err != nil) { return err } all day long. Go has generics, so why not magic the e r r o r into place and save the species a few billion keystrokes? > I honestly also don't see how retrofitting it wouldn't be trivial. I'm not the first to propose this. Others have and the naysayers are legion, citing one corner case after another. I argue that the corner cases aren't worth solving, perfect being the enemy of good. The complier is free to bail on whatever outlier gymnastics someone might try. > One could probably even write a preprocessor for that. I (and many others) abhor the concept of a precompiler/macrowhatever for Go (although some have resorted to them for reasons.) Go is supposed to be a fast and self contained; embiggening the tool chain with more stuff is the opposite of the intent of Go. > it will lead to less explicit error messages f := os.Open(savegamepath) ?("Couldn't load savegame: %s", err) f := os.Open(savegamepath) ?{decorateAndReturnError(err) {...}} Or similar perhaps. Error handling is common. It's worth bending the rules a bit for a gain in concision. A little pragmatism would go a long way here.

topspin 4y ago

> What's the benefit of the result type here Only to be consistent with the more general case: func tryToGetSomething() Result<Something> {...} Or perhaps you mean why not: func CopyFile() Result<error> {...} Yeah, sure. I don't care. I'm just tired of typing and wading through if (err != nil) { return err } all day long. Go has generics, so why not magic the e r r o r into place and save the species a few billion keystrokes? > I honestly also don't see how retrofitting it wouldn't be trivial. I'm not the first to propose this. Others have and the naysayers are legion, citing one corner case after another. I argue that the corner cases aren't worth solving, perfect being the enemy of good. The complier is free to bail on whatever outlier gymnastics someone might try. > One could probably even write a preprocessor for that. I (and many others) abhor the concept of a precompiler/macrowhatever for Go (although some have resorted to them for reasons.) Go is supposed to be a fast and self contained; embiggening the tool chain with more stuff is the opposite of the intent of Go. > it will lead to less explicit error messages f := os.Open(savegamepath) ?("Couldn't load savegame: %s", err) f := os.Open(savegamepath) ?{decorateAndReturnError(err) {...}} Or similar perhaps. Error handling is common. It's worth bending the rules a bit for a gain in concision. A little pragmatism would go a long way here.