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

[Andrei Alexandrescu]

On 6/23/20 8:19 AM, Steven Schveighoffer wrote:
> On 6/23/20 5:45 AM, Mathias LANG wrote:
>> On Tuesday, 23 June 2020 at 05:26:21 UTC, Andrei Alexandrescu wrote:
>>> 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.
> 
> Yes, I agree. It works because of the implicit conversion.

No, it doesn't work because of the implicit conversion, although 
implicit conversion is part of it. It works because there's a hack in 
the compiler that introduces the conversion from const(T[]) to 
const(T)[] automatically for template functions. It never happens for 
any other type - templates in D bind types "perfectly" otherwise. This 
is one exception.

> It's this case where it affects the result:
> 
> void fun(T)(T a) { pragma(msg, T.stringof); }
> 
> void main()
> {
>     const int[] a;
>     const(int)[] b;
>     fun(a);
>     fun(b);
> }
> 
> You only get one instantiation there.

Yes, this is illustrating the hack.

> The case makes complete sense, because the head is always a different 
> memory location (a copy). What we lack is a way to make the head mutable 
> of any type via a type modifier, so it's a "special case" in the sense 
> that it's possible only on T[] and T*. If we change the special case to 
> a general case, then it naturally makes things a lot more usable, and 
> gets rid of a lot of the complaints about const ranges.

Correct, thanks. That's where T.opOnCall() would fit in - the function 
would effect a change of type when an object of type T is passed by 
value to a template function. It sounds awfully particular, but I'm 
encouraged by the fact that it has worked so well for so many years with 
arrays and pointers.