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

[Steven Schveighoffer]

On 6/20/20 8:12 PM, Andrei Alexandrescu wrote:
> On 6/20/20 3:03 PM, Steven Schveighoffer wrote:
>> On 6/20/20 6:43 AM, Paul Backus wrote:
>>> On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
>>>> On Fri, Jun 19, 2020 at 09:14:30PM -0400, Andrei Alexandrescu via 
>>>> Digitalmars-d wrote: [...]
>>>>> One good goal for std.v2020 would be to forego autodecoding 
>>>>> throughout.
>>>> [...]
>>>>
>>>> Another could be to fix up the range API -- i.e, reconsider the 
>>>> ugliness that is .save, now that D has copy ctors.
>>>>
>>>>
>>>
>>> Also, switch from `void popFront()` to `typeof(this) rest`, so that 
>>> we can have `const` and `immutable` ranges.
>>
>> How does that work? You'd have to use recursion I guess? ugly. Why do 
>> we need ranges for something like this?
> 
> Think Hakell lists. They can implement tail easily (just return the next 
> pointer) but can't define popFront.
> 

My question wasn't about how such a thing could be implemented, but how 
it works with const ranges.

foreach(x; someConstRange) I think wouldn't be possible. I think you'd 
have to recurse:

void process(const Range r)
{
    subProcess(r.front);
    process(r.rest);
}

The point is to question the statement "so that we can have `const` and 
`immutable` ranges".

Sure, we could implement recursive versions of find, etc. I don't know 
if that's worth it.

-Steve