On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
> Versioning Phobos would free us from maintaining backward compatibility with a variety of decisions that did not withstand the test of time:

I think language and std lib should follow the same versioning scheme with the same attitude to breaking changes. Nobody wants to use the older outdated std lib.

Basically, if you are willing to break the std lib, then you also should be willing to have breaking changes at the language level.

On Tuesday, 26 October 2021 at 07:04:31 UTC, Sebastiaan Koppe wrote:
> On Tuesday, 26 October 2021 at 06:03:38 UTC, sarn wrote:
>> On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
>>> Goals of library versioning:
>>>
>>> - avoid copy-and-paste code duplication across versions
>> This might be overengineering.  Unless new features are going to be backported to the original std, is there anything wrong with just forking std to std2?
>
> Yeah, I kind of agree there, just copy the stuff. Simple and effective; no crazy mixins or module aliases.

Yeah, this "no copy paste" is a bad requirement that is stonewalling the proposal.

If the concern is about backporting bug fixes, git can handle that semi-automatically (and it can be fully automated in many cases by a PR hook script) since it knows the common ancestor.

On 10/26/21 12:58 AM, zjh wrote:
> On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
>> Versioning Phobos would free us from maintaining backward
> 
> can we improve this
> ```d
> if (isInputRange!(Range1) && isInputRange!(Range2))
> ```
> to:
> ```d
> if isallInputRange(Range1,Range2)
> ```
> ?
> `C++`'s `concept` is very grace.

There's https://github.com/dlang/phobos/pull/8303 that does something similar along with making mismatch variadic.

On 10/26/21 3:04 AM, Sebastiaan Koppe wrote:
> On Tuesday, 26 October 2021 at 06:03:38 UTC, sarn wrote:
>> On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
>>> Goals of library versioning:
>>>
>>> - avoid copy-and-paste code duplication across versions
>> This might be overengineering.  Unless new features are going to be backported to the original std, is there anything wrong with just forking std to std2?
> 
> Yeah, I kind of agree there, just copy the stuff. Simple and effective; no crazy mixins or module aliases.

Indeed that's simple and would allow trivial concurrent use of the two libraries.

I foresee the following challenges:

* Evolution to future versions. Does copying the whole codebase and tweaking it scale to e.g. annual releases of Phobos? Five years from now we'll have essentially five copypastas. How do you maintain them?

* For maintenance across versions, Adam proposed in discord that we leverage git patching. You copy the codebase, master is the most recent, and bugfixes are cherry-picked into previous releases (which are copies of the git tree at defined points in time). I am unclear (as others on discord seem to be) about how well this will work and what to do when it breaks - e.g. cherry-picking fails etc. Judging by an old refactoring PR that I'm trying to rebase - https://github.com/dlang/phobos/pull/7638/files - it is nigh impossible. And that's just a refactoring that doesn't aim to change semantincs, unlike phobos evolution. I am worried this will become a huge drag that will discourage us from doing maintenance as much as we are not discouraged from doing evolution. We should aim for both.

On 10/26/21 3:18 AM, Andrea Fontana wrote:
> On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
>> [...]
> 
> Probably not the best idea but also this should work:
> 
> std.... >
> 
> version(NEW)
> {
> .....
> }
> else
> {
> ....
> }
> 
> std2...>
> 
> version = NEW

This will grow with the number of releases.

I regret I forgot to mention in the initial post that we're not looking at v2. We're looking at v2, v3, v4, ... released e.g. at an annual or trienal pace. It's the having a fish vs. knowing how to fish problem.

On 10/26/21 10:53 AM, Paul Backus wrote:
> On Tuesday, 26 October 2021 at 14:41:38 UTC, Andrei Alexandrescu wrote:
>> I foresee the following challenges:
>>
>> * Evolution to future versions. Does copying the whole codebase and tweaking it scale to e.g. annual releases of Phobos? Five years from now we'll have essentially five copypastas. How do you maintain them?
> 
> Simple: release the new version on code.dlang.org, and don't merge it into Phobos proper until its API is stable and it's had time to fully bake. No need for annual releases, no need for multiple rounds of copy-pasta.
> 
> As far as I can tell all past experience should tell us that Phobos is a bad place to develop new code, and code.dlang.org is a good one. Consider `sumtype`: it began development in 2018 as a dub package, and was merged into Phobos in 2021 after reaching version 1.0. Meanwhile, `std.experimental.allocator` was started several years *before* `sumtype` (git history goes back to 2015), but still has not reached a stable, finished state.

That definitely should be the way for any new component to be added. For incremental evolution of the entire library (e.g. no autodecoding, reduce use of the GC and exceptions), putting the code elsewhere has the same issues as copypasta.

On Tue, Oct 26, 2021 at 08:43:19AM -0600, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> It's the having a fish vs. knowing how to fish problem.

Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.

;-)


T

-- 
People walk. Computers run.