isNonEmpty

Evolution Pitches
22

Of course it's used commonly and together; that's exactly what's expected of standard library facilities: that they are used commonly in combination with each other.

The core team has made it clear that isNotEmpty is not to be included in the standard library--in fact, it is the example of what will not be included. Likewise, alternatives to ! for negation are a commonly rejected change. I really don't see what's being accomplished here by discussing further.

4 Likes
23

I guess I'm arguing two things:

  1. Perhaps it is isNonEmpty that should be in the standard library, and not isEmpty. Because of the way Swift is put together, e.g. with guard.
  2. Perhaps it would make sense to use statistics to argue the likes of isEmpty / isNonEmpty instead of treating all boolean properties the same.
24

I think that I use isEmpty more often in the negated form — but !isNonEmpty would feel a little bit weird.
Isn't there an established word for a populated collection in the English language? :-)

25 
extension Collection {
    public var containsAtLeastOneElement: Bool {
        return !isEmpty
    }
}

Would be a huge gain for the stdLib. :laughing:

26

As I read this, I immediately thought on a @Ben_Cohen comment in one thread [coincidentally on an isNotEmpty discussion]. As Ben stated:

I think there's a real risk with the current pitches that we end up with a standard library populated with huge quantities of sugar and not enough protein.

Here's his full comment:

27

I did see that one, and I agree that Swift should not have both cases of all boolean properties. If that was needed, then it was an indicator of an underlying issue in Swift.

But I do think that the check for non-emptiness is special, and I don't think any perceived lack of protein should mean holding back on the sugar :wink:

BTW, I'm not advocating isNotEmpty, as the negative of isEmpty. I'm advocating isNonEmpty as a check for something being non-empty and hence useful for further processing. A key concept in Swift IMO. But perhaps this would be better solved by Collection.nonEmpty:

guard let array = array.nonEmpty {
28

hasElements, as Max Howell suggested above probably fits that bill best. (And happens to be the name I chose for this property personally, as I think it reads much better than the negative isNotEmpty in a guard's condition.)

1 Like
29

While hasElements is nice for collections, it doesn't fit e.g. Envelope very well :slight_smile:

30

Why not make it a language feature?

Automatically synthesise for boolean properties:

If the property has prefix is, has or will, automatically synthesise the corresponding isNot, hasNot, willNot.

For the other properties automatically synthesise the corresponding not. :slight_smile:

This might look like a bit of a funny thing, but in Swift we have "!" meaning two things: forcing (as in as!, try!, etc.), and negating (as in !myBool)

I would rather have only one meaning.

2 Likes
31

I find myself negating isEmpty more times than not.
Part of he problem may be that 'isEmpty' carries (for me at least) a tinge of negative meaning. I feel 'empty' as an absence of stuff, as a lack. Negating it feels a little like a double negative.

Does the positive sounding 'hasContent' help with the struggle to name the inverse?

if array.hasContent {

if !envelope.hasContent {

I spent a lot of time programming in Smalltalk. A postfix investor for boolean sounds fine to me.... but for others not.

2 Likes
32

I guess I could live with hasContent, but I prefer isNonEmpty :) Also, I'm not sure what the contents of an envelope is =)

33

The contents of an envelope are usually letters, but can often be postcards, greeting cards, or money. The phrase "the contents of an envelope" is perfectly reasonable English.

34

Fair enough :slight_smile:

How about the contents of a non-empty bounding box, then? =)

35

What is an empty bounding box please?

36

An empty bounding box is a box with zero area, hence not really bounding anything other than a single point I guess...

37

So the content of a non-empty bounding box is its area? Or am I missing something?
If so you might want to use hasContent rather than hasContents....

38

I think that's stretching it :slight_smile: It doesn't contain an area; it has an area.

But as I said, I could live with hasContent instead of isNonEmpty, although I would prefer the latter.

39

I believe .hasContent would still work for a type like BoundingBox, I can easily imagine it having methods like bbox.contains(point:) and bbox.contains(_ other:). It's harder to imagine how it would conform to Collection, at least if it is for 2D (or more) floating point coordinates.

1 Like
40

Yep, we can get hung up on semantics. It was worth exploring a bit to see if we could find a better term but I think we are overdoing it.

I still think it logical that a bounding box contains an area in the same way as an amazon box contains a volume (or a new shiny). Maybe that is because I do not tend to use them.

I dislike the negative feel of isNotEmpy, especially when negated (as it will be sometime). I prefer positive sounding terms, hence 'hasContent'. Perversely I feel isEmpty is weakly negative even though it is the opposite of isNotEmpty which is strongly negative.

I have no strong opinions on this - I have used languages with wildly different semantics and got used to them. Swift is a good language and the lack of sugar is part of that goodness. Minor semantic irritations are a small price to pay.

41

This is interesting. In our project isNotEmpty is also used more often than isEmpty.
isNotEmpty – 223 occurrences
isEmpty – 129 occurrences