Hello, I think that this topic had a point The is_not_empty() method as more clearly alternative for !is_empty()
I really don't like the is_not_empty naming but I think that calling this is_some (the same way an Option has is_some) is nice. I'm open to other names though.
I definitely appreciate the motivation here, but to move forward with it, we would need some resolution to the problem from the linked thread where there were 50 different name/syntax options that all made sense to one person but seemed wrong to another person.
Someone would need to articulate a strong argument that one particular choice is the one the community should agree on, or otherwise this will just end up like the other thread.
Note that option has is_some because it has a variant named Some -- the same reason that Result has an is_ok.
But we shouldn't be adding is_ok or is_some to arbitrary other types.
At this point it's just not worth it. The is_empty method exists on all collections in Rust, and similarly is_non_empty (or some other name) method should be also added everywhere. But there are already way too many collections existing in the ecosystem, and it's unrealistic to expect that they all will add a new method, moreover such a trivial one. This will increase the ecosystem-wide confusion rather than make things more clear. Some people may also dislike the naming, so you will have is_non_empty, has_elements, is_some, is_filled and all other possible combinations, which will only add to confusion.
The !x.is_empty() is well-established, and it's just not worth the trouble to try changing it. Rust's guarantees also make a mistake here unlikely to go unnoticed, it will be caught with a panic at runtime if not at compile time. Finally, the ! could be highlighted more prominently in the editors, and some people may adopt a more visible formatting ! x.is_empty().
It would be easier to change if is_empty were a trait method, but it isn't, and at this point it's also unlikely to be ever added.
I see the argument that has_something is better than is_empty because the latter is a "negative" question, and it's better to ask positive questions. But I also think by far one method is better than two methods. So unless you were going to deprecate is_empty, it's not worth it. Small APIs are a very important design criterion, bloated APIs are a very big cost in my mind.
More shed ideas
is_inhabited
has_tenants
unempty
ıs_occupied
is_populated
has_some
(if of course you are actually going to build a shed)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.