On Tuesday, 9 October 2012 at 13:22:28 UTC, Steven Schveighoffer
wrote:
[SNIP]
I tend to disagree with your examples, because, you are mixing
the notion of run-time failure with logic error.
For example: "new" New can fail. And you don't know unless you
try.
But new will throw an exception to tell you it failed..
An appender, as you say, is finite in memory, and will end up
throwing an exception, yes. You also have a chance to try to
catch it and react.
Over-putting into a finite slice, on the other end, will
*assert*. Game over. It is a catch 22: You can't know unless you
try, you crash if you do.
I'm not against defining a standard way to say "I'm full", but
proposing it *can't* say that is not the solution. Clearly, we
could do better in defining a standard way to test for fullness
(full property akin to empty?). Even so, putting into a
non-full range could generate an error.
Hum... I'm just kind of wondering here: Couldn't we simply have
put throw an actual exception? Something along the lines of
"OutputRangFullException"? That would be a pretty good compromise.
Performance wise, I don't think there'd be any real toll:
delegates/functions don't have empty anyways, so it would just be
a matter of catch-rethrow. As for input ranges, well, I think it
would be safer anyways if they checked and threw, rather than
blindly over pop and crash...
Didn't fully think this threw yet (just thought of it typing),
but I thought I'd throw it out there.
However, I really don't like having a range tell me "yeah, I'm
an Output Range", just to choke on the first call to put.
What about an input range that is immediately empty? These are
corner cases, but certainly valid.
Wouldn't "empty" simply answer "true" before even starting? At
least it is being honest.
-Steve
Thanks for debating.
