Proposal: Add `future::is_ready()` as a synonym for `future::ready()`

[Dan Bonachea]

Background

Currently member functions providing a boolean state query on a UPC++ library object generally follow the naming pattern {is,has}_[state]. Examples:

• atomic_domain::is_active()
• dist_object::is_active()
• dist_object::has_value()
• global_ptr::is_local()
• global_ptr::is_null()
• team::is_active()
• gpu_device::is_active()
• heap_allocator::is_active()

Problem

I believe the only current exceptions to this naming pattern are:

1. view::empty()
2. future::ready()

view::empty() inherits its name from the standard container library (e.g. std::vector::empty()), so should be familiar to novice users and seems unlikely to cause confusion.

However, future::ready() deviates from this naming pattern for no good reason I can ascertain, aside from historical inertia. Worse, the name ready could be misread by naive users as a command (e.g. "please ready this future") potentially degrading intuition regarding correct use of UPC++ futures.

Proposal

Specify future::is_ready() as an alias for future::ready(), deprecate the old spelling and encourage use of the newer more explicit spelling in new code.

[Dan Bonachea]

Proposed resolution in spec PR 102 and impl PR 492

[Dan Bonachea]

Spec future::is_ready() and deprecate future::ready()

Resolves issue #206

→ <<cset 4751f2249498>>