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

[Andrei Alexandrescu]

On 6/23/20 5:45 AM, Mathias LANG wrote:
> 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.

I don't understand the difference. The change $qual(T[]) -> $qual(T)[] 
happens specifically when a template parameter type is deduced for a 
function call.

> To me this makes perfect sense: This little peculiarity allows us to 
> reduce the amount of template instantiations.

As I said before, I appreciate there's no shortage of people ready to 
explain things I've done back to me. In this case it's actually Walter's 
work. A long time ago, shortly after we introduced ranges and algorithms 
to Phobos, people complained (including in this forum) that there was no 
way to use algorithms with constant arrays. Walter and I talked about it 
for a while and he introduced this glorious hack, only for arrays and 
only for template function calls. Suddenly const arrays started to work, 
and nobody complained about the lack of generality of the hack. Until 
now I guess!

> 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);
> }
> ```

This example is actually not illustrative. The first call involves a 
conversion from immutable(int[]) to immutable(int)[]. This happens even 
for non-templates. The second call involves a conversion from int[] to 
const(int[]), again a standard conversion. Neither call involves the 
hack discussed here, which is const(int[]) to const(int)[].

> 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)[]`
> }
> ```

That'd work but would not improve the problem of working with const ranges.