OutputRange should be infinite?
monarch_dodra
monarchdodra at gmail.com
Sat Oct 6 01:07:41 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