On Thu, 27 Mar 2014 00:17:21 -0400, Walter Bright
<[email protected]> wrote:
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.
Like range.save. It's "required", but frequently omitted, without any
consequences. I'm not saying requiring it would be an invalid decision,
I'm saying requiring it would be a futile gesture -- the requirement would
be ignored.
What happens when one of our "clients" code breaks severely because we
make a change in phobos that assumes empty is always called first on a
newly-created range?
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.
I think we should work on making a protocol that does not require awkward
calls, rather than alienating developers who don't follow the awkward
protocol.
BTW, I think there has been recent talk about not focusing on dust when we
are laying bricks. This would have my vote as useless dust. This does not
solve the problem of streams-as-ranges, because streams don't make good
ranges. It doesn't really solve any problems as far as I can tell.
-Steve
