[SERVER-26458] Add explicit bool() to Status/StatusWith Created: 04/Oct/16 Updated: 29/Jan/18 Resolved: 12/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | Ted Tuckman |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | neweng, platforms-interns-2017 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Platforms 2017-06-19 |
| Participants: |
| Description |
|
It would be nice to be able to use them in an "if" statement. |
| Comments |
| Comment by Ted Tuckman [ 12/Jun/17 ] | |||||||
|
As discussed with adam.martin, ben.shteinfeld and tyler.kaye we've decided not to add explicit bool. For readability and ease of use it makes more sense to keep the way of accessing status as "status.isOK". Changing this to be either if(status) {error} or if(!status) {error}would make these more confusing. Continuing to use status.isOK does not have this issue and is not harder to use. | |||||||
| Comment by Mira Carey [ 10/Oct/16 ] | |||||||
|
I think it's something most people will trip over once, if at all, then internalize as error codes (posix libc or otherwise). I'm inclined to improve ergonomics where a natural analog exists | |||||||
| Comment by Andy Schwerin [ 07/Oct/16 ] | |||||||
|
I've held off from this in the past because my most common if statement is the following:
Which makes it natural to want the operator bool to return true when status.isOK() == false. This is consistent with posix libc errors, where false returns mean "operation succeeded", but I was worried it would be confusing. For example, if I wrote the following:
I'm afraid readers wouldn't know how to interpret it. But maybe that fear is overblown. |