Back in September, Ned submitted an ENH with some methods that are used 
by the RB.  One set of methods were the #ifEmpty/#ifNotEmpty: 
variations.  After some discussion, it seemed there was consensus to add 
these methods in forms that take 0-arg blocks as arguments (original 
message quoted below).

Does this need to get posted as a new, separate ENH?  I tried to check 
if it had already been put into 3.7a, but the 3.7a images are 
segfaulting my VM and I don't have time to figure out building a new one 
atm.

I don't mind making and posting the changeset if desired, though because 
of the above I can't test it in the latest 3.7 right now.

Julian

Some time ago, Andreas wrote:
> Hi Daniel,
> 
>> > -1: SharedPool deliberately doesn't use dictionary 
>> >protocols.
>> Well ok, but - 
>> A. RB needs to know whether the bindings includes: name.
>> B. In 3.6 some pools are dictionaries.
> 
> I understand this. The point was that we should think hard about which
> protocols _do_ make sense for shared pools and for which ones we should make
> up new ones. I'm not decided on #keys by the way - most of the trouble is
> modifying pools and keys happens to be an inquiry. So I could live with
> that.
> 
>> > > 4. Collection>>ifEmpty:ifNotEmpty: and variations.
>> > -1: This should not be sneaked in as a "small change" given that it
>> > significantly extends the collection protocol.
>> Well, you caught me. Let the arguments begin :_)
>> 
>> > And is questionable in the
>> > semantics - the asymmetry between #ifEmpty: (0-arg block) 
>> > and #ifNotEmpty: (1-arg block) greatly disturbs me.
>> Ok. I can go for 0-arg #ifNotEmpty:. Then we're ok? anybody else have
>> strong feeling either way?
> 
> I'd be happy with any symmetric solution.
> 
> Cheers,
>   - Andreas