3 ms·
Yes, and the point I was making was that I don't think it actually makes things much clearer. One has more syntax and alters the effective return value, the ot
by bborud 5y ago
Yes, and the point I was making was that I don't think it actually makes things much clearer. One has more syntax and alters the effective return value, the other just states what you will get back regardless of result. From a practical point of view when you are consuming an API, which requires more concentration?
- Zababa 5y ago> From a practical point of view when you are consuming an API, which requires more concentration? I think the current Go one requires more concentration, or at least more work. Lots of functions return data, err. You have to check for each of these functions if the presence of err means that data is going to be invalid/nil or add it to your code. The same argument could be made for nil by the way. Since everything can be nil, you have to check for nil often. In languages that make a difference between a type, and a type or nil, this is easier.
- monocasa 5y agoThe one that doesn't attempt to tell me which will be valid in relation to eachother, so I have to go divine that rather than just reading the function signature?