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

[Andrei Alexandrescu]

On 6/22/20 10:33 AM, Steven Schveighoffer wrote:
> On 6/22/20 10:20 AM, Paul Backus wrote:
>> On Monday, 22 June 2020 at 12:15:39 UTC, Steven Schveighoffer wrote:
>>>
>>> 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.
>>>
>>
>> Well, currently, range algorithms can't work with const ranges *at 
>> all*, recursively or iteratively. So from a user perspective, this 
>> would be a strict improvement on the status quo.
> 
> Algorithms can work with const ranges -- as long as the range is an array:
> 
> const int[] arr = [1, 2, 3, 4, 5];
> 
> auto x = arr.find(3);
> 
> assert(x == [3, 4, 5]);
> 
> I think the better option is to focus on making it possible to duplicate 
> this possibility for generic ranges rather than implement a new and 
> awkward API.
> 
> FeepingCreature is right, we should try and create a head mutable 
> mechanism. I have envisioned it in the past as a tail-modifier mechanism 
> (e.g. tail-const).

Oh, indeed. Arrays are special cased by the compiler - const(T[]) is 
silently converted to const(T)[] when calling a function.

At a point there was a discussion about allowing a similar conversion to 
be done automatically by the compiler - opCall(). So whenever you pass 
an object to a function, if the type defines opCall, it would be 
automatically invoked.