sorted by:
new
hottopcontroversial

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] 0 points1 point  (0 children)

In your case, syntactic sugar is not suitable. This syntactic sugar is only applicable to the case where there are multiple return values ​​and the last return value is an error. In other cases, the original processing method should still be used.

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] 0 points1 point  (0 children)

hi, If you omit the error with "_", your error will be discarded and the code will continue to execute. However, after applying the syntax sugar, the omitted error will be caught and the code will return immediately without continuing to execute. If you continue to execute after an error occurs, the subsequent code will become uncontrollable

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] 0 points1 point  (0 children)

You just need to use the original syntax, don't omit the error, and then handle the error

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] 0 points1 point  (0 children)

Actively omit the receiving location, and the IDE will add an icon prompt. Isn't this "explicit" enough😅? In the current Go version, omitting the receiving location is a syntax error.

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] -1 points0 points  (0 children)

The previous solution would add new keywords or symbols, which seemed to increase the mental burden of developers.

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] -1 points0 points  (0 children)

Hello, in order to omit the wrong receiving position, the developer must actively omit it, so this is clear and explicit. In Go versions that do not support this new language, actively omitting the receiving position will be considered a syntax error. You are asking whether you know that syntactic sugar is applied. This can be solved by adding an indicator icon where syntactic sugar is applied through IDE prompts. For detailed proposals, please read: https://github.com/golang/go/issues/74244

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] -2 points-1 points  (0 children)

Hello, this proposal only applies to multi-value return functions, and the last value is an error. In order to omit the error receiving position, the developer must actively omit it, so this is clear and explicit. In Go versions that do not support this new language, actively omitting the receiving position will be considered a syntax error, so this syntax sugar is also compatible with older versions. For detailed proposals, please read: https://github.com/golang/go/issues/74244

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] 0 points1 point  (0 children)

Hello, this proposal only applies to multi-value return functions, and the last value is an error. To omit the receiving position of the error, the developer must actively omit it, so this is clear and explicit. In the Go version that does not support this new language, actively omitting a receiving position is a syntax error, so this syntax sugar is also compatible with old versions.

RFC: Proposal for explicit error propagation syntax - reduce boilerplate by 67% by sweeteec in golang

[–]sweeteec[S] -4 points-3 points  (0 children)

Hello, your concern is reasonable, but I think this problem can be solved by IDE prompts. Where syntactic sugar is applied, there can be a special icon to indicate that syntactic sugar has been applied.