std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Tue Jun 23 05:15:49 UTC 2020
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.
More information about the Digitalmars-d
mailing list