C++ std::future<T>方法命名：is_ready()还是ready()？实验名称疑问解析

Great question! This dives into the subtlety of STL naming conventions and how C++ standard proposals evolve. Let’s break this down clearly:

1. Naming Tradeoffs: is_ready() vs ready() #

First, it’s worth acknowledging that STL naming isn’t perfectly consistent (we’ve all seen exceptions like valid() sitting alongside is_lock_free() or is_directory()), but there’s a loose logic to the patterns:

• Adjective-style names (like valid(), empty(), full()) typically describe a core, intrinsic property of the object itself. For std::future::valid(), this checks if the future has an associated shared state—a fundamental part of the future’s own validity as an object.
• is_-prefixed names are often used for checking secondary or associated states that aren’t the object’s core identity. For is_ready(), we’re querying whether the shared state tied to the future has completed, not whether the future itself is valid. This prefix helps immediately signal that this is a boolean state check, not an action.

Another key point: ready() could easily be misinterpreted as a mutating method (e.g., something that forces the future to become ready) rather than a read-only query. The is_ prefix eliminates that ambiguity entirely.

2. Why is_ready() was selected as the experimental enhancement #

The proposals N3721 and N3865 included both names during the standardization process—this is common as the C++ Committee gathers feedback on API design. Here’s why is_ready() emerged as the preferred choice:

• Consistency with modern STL APIs: Many newer STL components use is_ for state-checking methods that query external or associated states (e.g., std::atomic::is_lock_free(), std::filesystem::is_regular_file()). Aligning std::future with this pattern makes the API more predictable for developers already familiar with other parts of the library.
• Clarity over strict exception alignment: While valid() exists without the prefix, it’s an older API. Newer additions to the STL tend to prioritize consistent naming patterns where possible, even if it means deviating from a single older exception.
• Feedback-driven choice: During proposal reviews, the Committee likely received feedback that is_ready() was more intuitive and less ambiguous than ready(), making it the better fit for a future standard addition.

内容的提问来源于stack exchange，提问作者Daniel Eiband