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