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

[jmh530]

On Thursday, 18 June 2020 at 14:16:13 UTC, Jesse Phillips wrote:
> On Saturday, 13 June 2020 at 20:37:59 UTC, jmh530 wrote:
>> One problem is that if you allow people to make bug fixes to 
>> old phobos versions, then there is no way for the subsequent 
>> releases to get the updates as if you could with a git branch. 
>> You would have to do them all manually.
>>
>
> Git will allow you to create a patch from one file and apply it 
> to another. Still manual.
>
> [snip]

I think Andrei had made a good point about propagating up 
changes. This would imply keeping the structure that I had 
previously for std.algorithm overall, but modify the N_NN module 
files. For instance, if one were starting from 2_89, then that 
would be unchanged, while 2_90 would be

module 2_90.std.algorithm;
public import 2_89.std.algorithm: funA, funC, funD...;
void funB() {}

and so on up. For an even more fine-grained basis, you could do

module 2_90_0.std.algorithm;
public import 2_89.std.algorithm: funA, funC, funD...;
void funB() {}

module 2_90_1.std.algorithm;
public import 2_90_0.std.algorithm: funA, funC, funD...;
void funB() {}

module 2_90.std.algorithm;
public import 2_90_1.std.algorithm;

So this would work pretty well in terms of minimizing the amount 
of code re-use going on.

(there is probably scope for a mixin that can do those imports, 
or a new language feature "import module: -f" that imports 
everything except f)

With respect to your suggestion, suppose you release some patch 
for funB in 2.90.1 late, i.e. when the current version is 2.95 or 
something. If funB has not been changed over this period, then it 
propagates up without issue (note that the import of 2_89 would 
not be over the patch, 2_89 would be structured like 2_90). 
However, if funB has changed, then future updates will not 
benefit from it. You would have to manually update those as well. 
Your suggestion would be useful in this case, I think.