std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]
Paul Backus
snarwin at gmail.com
Fri Jun 26 16:03:23 UTC 2020
On Friday, 26 June 2020 at 14:46:24 UTC, Joseph Rushton Wakeling
wrote:
> 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?
Because const and immutable are transitive, any data structure
that includes a range, either directly or by reference, is itself
forced to be mutable. This makes D's const and immutable
significantly less useful than they otherwise would be; i.e., it
makes D a worse language.
The fact that you, personally, cannot think of a use-case for
immutable ranges off the top of your head is not a strong
argument against supporting them. All language and library
features ought to work together unless there is a specific reason
for them not to (as is the case, for example, with garbage
collection and BetterC).
So I think the burden of proof is on you here. If we're designing
a new range interface, is there a good reason it *shouldn't* work
with const and immutable?
One argument in favor of requiring mutability is that using
tail() instead of popFront() could result in a loss of
performance. I am working on investigating that claim using the
examples provided by Jon Degenhardt earlier in this thread.
Another, which I find less convincing, is that writing algorithms
recursively instead of iteratively would be too "difficult" or
"onerous". If you have any more to add, I am interested in
hearing them.
[1] https://issues.dlang.org/show_bug.cgi?id=5377
More information about the Digitalmars-d
mailing list