OutputRange should be infinite?

[monarch_dodra]

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.