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

[Andrei Alexandrescu]

On 6/22/20 6:17 PM, Paul Backus wrote:
> On Monday, 22 June 2020 at 21:46:51 UTC, Andrei Alexandrescu wrote:
>> On 6/22/20 12:50 PM, Paul Backus wrote:
>>>
>>> The trick used for arrays does not only apply to function calls:
>>>
>>>      const(int[]) a = [1, 2, 3];
>>>      const(int)[] b = a; // compiles
>>
>> That's different - it's an implicit conversion.
>>
>>> IMHO the principled way to allow user-defined implicit conversions 
>>> is...to allow user-defined implicit conversions. But iirc that's a 
>>> can of worms Walter prefers not to open.
>>
>> What happens upon function calls is not an implicit conversion. It's a 
>> forced type change.
> 
> So what you're saying is, it's even *less* principled than I thought? :)

Yeah, it's a hack, but it works very well.

> Regardless, my broader point is that once we're open to the possibility 
> of designing a new range API, all of this can be solved without any 
> language changes by using an API that doesn't require mutation (i.e., 
> tail()).

Using only tail() makes iteration with mutable ranges inefficient and 
iteration with immutable ranges difficult (must use recursion 
everywhere). Hardly a winner of a design contest.

>  Surely that's a better solution than implicitly inserting calls 
> to arbitrary user-defined code every time someone passes an argument to 
> a function.

If there is, we haven't found it.