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

[Andrei Alexandrescu]

On 6/22/20 12:50 PM, Paul Backus wrote:
> On Monday, 22 June 2020 at 16:42:55 UTC, Andrei Alexandrescu wrote:
>> On 6/22/20 12:14 PM, Paul Backus wrote:
>>> Making it work in general requires either subverting the type system 
>>> (like Rebindable does) or adding more special cases to the language.
>>
>> The principled approach is to generalize the trick currently used only 
>> for arrays. Consider the lowering:
>>
>> "Whenever something is passed to a function, .opOnCall is appended."
>>
>> Then:
>>
>> auto ref T opOnCall(T)(auto ref T x) { return x; }
>> const(T)[] opOnCall(T)(const(T[]) x) { return x; }
>> immutable(T)[] opOnCall(T)(immutable(T[]) x) { return x; }
>>
>> This is just a sketch, haven't thought it through, but if properly 
>> defined the scheme would work having built-in arrays work as they are 
>> today, and would also allow user-defined types to define their own 
>> opOnCall as they find fit.
> 
> 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.