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

[Mathias LANG]

On Tuesday, 23 June 2020 at 05:26:21 UTC, Andrei Alexandrescu 
wrote:
> On 6/22/20 11:22 PM, Mathias LANG wrote:
>> On Monday, 22 June 2020 at 21:46:51 UTC, Andrei Alexandrescu 
>> wrote:
>>> On 6/22/20 12:50 PM, Paul Backus wrote:
>>>
>>>> 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.
>> 
>> Can you expand on this ? I've never heard of this before.
>
> https://run.dlang.io/is/KgeosK
>
> Yah it's kinda surprising innit. For regular functions it's 
> business as usual - exact match is attempted, conversions are 
> considered etc. const(T[]) is convertible to const(T)[], 
> nothing new about that.
>
> For template functions however, although templates always do 
> exact match, arrays surreptitiously change their type from 
> const(T[]) to const(T)[], without a conversion in sight.
>
> We need to offer that chance to other ranges if we want them to 
> enjoy a similar treatment.

So it's not on function call, but it's about the type being 
deduced. There's quite a big difference here.

To me this makes perfect sense: This little peculiarity allows us 
to reduce the amount of template instantiations. E.g. the 
following code will only instantiate a single template:
```
void fun2(T)(const T[] a) { pragma(msg, T.stringof); }

void main() {
     immutable(int[]) a;
     fun2(a);
     int[] b;
     fun2(b);
}
```

In fact I'd love if we extend that to `auto` so the following 
code would work:
```
immutable(int[]) fun2() { return null; }

void main() {
     auto x = fun2();
     x = fun2(); // Currently `x` is `immutable(int[])` not 
`immutable(int)[]`
}
```