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
But we shouldn't be adding
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_filled and all other possible combinations, which will only add to confusion.
!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
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
(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.