On 3/26/2014 7:55 PM, Steven Schveighoffer wrote:
OK, but it's logical to assume you *can* avoid a call to empty if you know
what's going on under the hood, no? Then at that point, you have lost the
requirement -- people will avoid calling empty because they can get away with
it, and then altering the under-the-hood requirements cause code breakage later.
Case in point, the pull request I referenced, the author originally tried to
just use empty to lazily initialize filter, but it failed due to existing code
in phobos that did not call empty on filtered data before processing. He had to
instrument all 3 calls.
As with *any* API, if you look under the hood and make assumptions about the
behavior based on a particular implementation, assumptions that are not part of
the API, the risk of breakage inevitably follows.
If you've identified Phobos code that uses ranges but does not follow the
protocol, the Phobos code is broken - please file a bugzilla issue on it.
