On Saturday, 6 October 2012 at 05:24:06 UTC, Steven Schveighoffer
wrote:
On Fri, 05 Oct 2012 11:15:44 -0400, monarch_dodra
<[email protected]> 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.
