OutputRange should be infinite?

Steven Schveighoffer schveiguy at yahoo.com
Tue Oct 9 05:58:29 PDT 2012


On Sat, 06 Oct 2012 04:07:41 -0400, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> 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"?

try doing this on a unix system

cat /dev/zero > ~/zeros

And see if the output file zeros is infinite :)

Even an appender is finite when you run out of memory.

Do you think output files make bad output ranges, even though they are  
finite?

An output range is nothing but an interface to a storage location.   
Whether the storage location is infinite or not is up to the location, the  
output range has to support both infinite and finite targets.

What you are proposing would make it illegal to use std.algorithm.copy on  
*any* memory-based construct, or else have it blissfully succeed by  
throwing away any extra data.  Neither of these situations are tenable.

>> 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".

No, definitely not.  An output range can take input, but must obviously be  
able to say "I'm full".

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

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.

> 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.

-Steve


More information about the Digitalmars-d mailing list