std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.com
Mon Jun 22 16:03:54 UTC 2020
On 6/21/20 1:43 PM, Stanislav Blinov wrote:
> Input ranges, by nature being one-pass, *should not be copyable*. You
> can't do anything (good) with a copy, and have to invest into
> implementing a copy that won't bite. If you're giving such range away -
> you're giving it *away*, to someone else to consume. It being copyable
> only means that you're leaving for yourself a mutable reference to state
> that you shouldn't touch again. When you need the remainder back - your
> callee will move it back.
Good arguments, no doubt, but a long experience with noncopyable C++
objects suggests that defining such types need to be approached with
trepidation as they are very cumbersome to use. (Any type containing a
noncopyable type as a member becomes itself noncopyable; this is not
something that we can inflict lightly on the casual users of input
ranges. (To wit: no input streams or iterators in C++ are noncopyable,
although the same argument would apply to them as well.)
Also, it is not unheard of to have two input ranges fed from the same
source with the obvious semantics (whoever calls functions to get more
data will get the data and push the cursor further). True, buffering is
an issue (what if two copies have each their own buffers?) but that's an
engineering problem, not one of principles.
It is quite clear to me that we can't propose a design with noncopyable
input ranges without effectively making them pariahs that everybody will
take pains to use and do their best to avoid.
More information about the Digitalmars-d
mailing list