On Monday, 1 November 2021 at 15:39:46 UTC, Andrei Alexandrescu wrote:
> On 11/1/21 10:09 AM, Ogi wrote:
>> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/phobos/pull/8309
>>>
>>> Destroy!
>> 
>> Good stuff.
>> 
>> Notably absent are `std.range.interfaces`. What are we going to do about them?
>
> I don't think they need particular attention - either publish them as they are, change them, or give up on them altogether (I believe allowing ref-type ranges was a mistake).

Easiest thing would be to wrap the class reference in a struct that calls `save` in its copy constructor, but does not expose a `save` method to its users:

import std.range.interfaces;

struct ForwardRangeObject(E)
{
    private ForwardRange!E payload;

    @property auto ref front() { return payload.front; }
    // etc.

    this(ref inout typeof(this) other) inout
    {
        payload = other.payload.save;
    }
}

On 2021-11-01 13:49, 12345swordy wrote:
> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>> https://github.com/dlang/phobos/pull/8309
>>
>> Destroy!
> 
> All I can think of is "Why can't we used a package manager for Phobos?".

A package manager solves problems orthogonal to those solved by this proposal.

On Monday, 1 November 2021 at 13:38:44 UTC, Ola Fosheim Grøstad wrote:

>> This is an argument in favor of versioning. V1 can have all those properties, and subsequent versions can build on it.
>
> If you only extend, but then you don't need explicit versioning. Versioning the language/compiler would be sufficient.

Maybe I'm not understanding, but if V1 includes, say, std.range.primitives, you would know you could always rely on everything in it to work exactly the same way for the next 50 years. V2 would include the first stab at std.range.interfaces, V3 would include a different version of std.range.interfaces that takes advantage of the things we've learned, and the end user could decide which to use. It's true that you wouldn't need versioning of std.range.primitives, but it's still part of the standard library and you'd need some way to identify that it's guaranteed to not change, so calling it V1 would be convenient. It wouldn't hurt anything to have only one version of some functionality.

On Monday, 1 November 2021 at 18:55:34 UTC, Andrei Alexandrescu wrote:
> On 2021-11-01 13:49, 12345swordy wrote:
>> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/phobos/pull/8309
>>>
>>> Destroy!
>> 
>> All I can think of is "Why can't we used a package manager for Phobos?".
>
> A package manager solves problems orthogonal to those solved by this proposal.

How is the old Phobos libraries are going to be distribute then? As part of the compiler bundle?

-Alex

On 2021-11-01 15:12, 12345swordy wrote:
> On Monday, 1 November 2021 at 18:55:34 UTC, Andrei Alexandrescu wrote:
>> On 2021-11-01 13:49, 12345swordy wrote:
>>> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>>>> https://github.com/dlang/phobos/pull/8309
>>>>
>>>> Destroy!
>>>
>>> All I can think of is "Why can't we used a package manager for Phobos?".
>>
>> A package manager solves problems orthogonal to those solved by this proposal.
> 
> How is the old Phobos libraries are going to be distribute then? As part of the compiler bundle?
> 
> -Alex


They come with the distribution, yes.

In fact the way the PR is structured, it includes both versions in the same library. That's not a large increase in size because there same artifacts are used wherever appropriate.

On Monday, 1 November 2021 at 17:32:21 UTC, Andrei Alexandrescu wrote:
> On 11/1/21 10:54 AM, user1234 wrote:
>> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/phobos/pull/8309
>>>
>>> Destroy!
>> 
>> Two questions, probably related to `canon`. I assume that two things are possible but I dont see how:
>> 
>> 1. How does the module identifier part `v1` binds a current module name ?
>> For example the fact that `import std.v1.file` is the same as `import std.file`.
>
> I don't understand this question, can you please rephrase?

Based on the answer to the second question I think that what was asked in the first is not possible.

On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/8309
>
> Destroy!

On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

D and Phobos 2.000 and 2.098 (as their version are tightly coupled) went though so many versions and deprecations it's getting confusing to keep track what works and what used to work. I sometimes have to search changelogs to keep code compatible between releases across operating systems. A compiled list of features with their version ranges would be pretty big.

I think it'd be safe to do D3 as well, because this also includes language changes throughout the decade (I think D2 was from 2008!).

Do take this as a grain of salt, I transitioned from .NET to D in around 2016 so maybe I am a little used to having my library (e.g., .NET 4.5.2) and my language (e.g., C# 7) separated.

But curious what std.v2 will bring. Will keep an eye open!

On 10/30/21 9:59 PM, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/8309
> 
> Destroy!

Made a change to the PR - now the new package is called "std.v2alpha" so as to clarify the transition process:

1. Add std.v2alpha
2. Add to std.v2alpha while continuing with the normal pace of releases
3. When everyhing in v1 was ported to v2, rename v2alpha to v2 and release.

That way we can implement complex versions without blocking the release process for a long time.