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