std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Fri Jun 26 14:46:24 UTC 2020


On Wednesday, 24 June 2020 at 16:08:05 UTC, Andrei Alexandrescu 
wrote:
> On 6/24/20 10:17 AM, Joseph Rushton Wakeling wrote:
>> I'm struck that no one AFAICS has suggested the following 
>> alternative: instead of `tail`, to allow popFront() (and if 
>> implemented, popBack()) to return an `Option!(ElementType, 
>> None)`.
>> 
>> What is returned would be either the popped element, or None 
>> if no more elements remain (with the nice by-product of no 
>> longer getting assert failures if pop{Front,Back} are called 
>> when the range is empty).
>
> I think the discussion about tail() had to do with immutable 
> ranges. Having popXxx() return something would still have it 
> mutate the range.

Ah, gotcha, thanks, I'd missed that context.

Nevertheless, I'd like the option-returning popFront to be 
considered on its own merits, because it seems to me to add 
useful distinctions between what input and forward ranges to do.

On immutability: it feels like this relates at least in part to 
not necessarily distinguishing adequately between ranges versus 
containers (or more generally, ranges versus owners of memory).

Have I missed anything in noting that ranges can be divided 
roughly along the following lines:

   - processing external input, where the internal state is just 
some small
     memory buffer or other collection of variables used to store 
the latest
     data read

   - generative mechanisms where the range elements are produced 
by a sequential
     algorithm

   - iteration across data stored in memory

... where immutability only really makes sense in the first place 
w.r.t. the last of these?  And there, it doesn't really make 
sense that the range be const or immutable -- only that the 
underlying data is?


More information about the Digitalmars-d mailing list