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