OutputRange should be infinite?

monarch_dodra monarchdodra at gmail.com
Sat Oct 6 01:10:17 PDT 2012


On Saturday, 6 October 2012 at 05:24:06 UTC, Steven Schveighoffer
wrote:
> On Fri, 05 Oct 2012 11:15:44 -0400, monarch_dodra 
> <monarchdodra at gmail.com> wrote:
>
>> However, I that the "isOutputRange" definition should require 
>> infinite-ness, as mentioned by others.
>
> No, this is very wrong.  A slice is an output range, but is 
> finite.

A slice is an input range and can safely be used as such. What is
the merit of *also* defining it as an output range? Why even
bother with defining "OutputRange" if it just means "InputRange"
+ "functions"?

> If you are putting something that is larger into something that 
> is smaller and cannot be extended, I would expect an error.  
> You don't?

Yes, but as shown the semantics of "put" are basically: "Cram
*anything* you want inside of me. I can take it".

As evidenced by my two examples, this is clearly not the case,
and, even worse, the developer has _no way_ of knowing this.

> [SNIP]
> -Steve

Long story short, the *only* reason to ever use the "OutputRange"
interface over the "InputRange" interface is:
*When cramming things into a delegate. (which are/should be
infinite by design)
*When cramming things into an input range, but not caring about
capacity.

I'm just saying, "put" is convenient and all, and I have no plan
to have it changed. Users can use it at their own discretion if
they want to use it on an InputRange, and at their own risk.

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.


More information about the Digitalmars-d mailing list