On 2021-11-02 13:03, Robert burner Schadek wrote:
> On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu wrote:
>>> Destroyed!
>>
>> I agree with most of your points and definitely love the enthusiasm. But it seems to me you are looking at a one-off revolution and what we must define is a reproducible process. One does not exclude the other.
> 
> Not it all, std2 sounds to me like std.experimental just with a different name.

Must have been a miscommunication on my part. The two couldn't be more different.

std.experimental:

- NEW, as-of-yet unproven stuff
- Everything can change without notice
- Intent is to be moved to std when ready, where it ADDS functionality
- No changes that break std

std.v2:

- Fundamentally makes all existing functionality in std available
- Breaking API changes are possible, designed, and announced
- Additions are also possible, designed, and announced, but not quintessential (e.g. v2 with no autodecoding and improvements to safe, nogc, and nothrow would be a solid release)
- Intent is to coexist with std forever, with an eye toward deprecating the previous versions

I'd say any parallel between std.v2 and std.experimental is tragically misguided.

On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu wrote:
>> Not it all, std2 sounds to me like std.experimental just with a different name.
>
> Must have been a miscommunication on my part. The two couldn't be more different.

I don't think the concern is that they are _intended_ to be similar, but that they will end up that way.

> std.experimental:
> - Intent is to be moved to std when ready, where it ADDS functionality

And yet, std.experimental seems to be where code goes to die.  std.sumtype exists, probably only because pbackus didn't let it go into std.experimental.

std.v2 is similar in at least one respect: it does not start off stable, and will presumably get that way at some point.  At what point do we say 'std.v2 is now stable'?  Well, that's exactly the same question we ask about things in std.experimental.


Here's one way it could be done: stabilize individual components of it at a time.  So, say: get rid of autodecoding and maybe the class range thing, and then say 'all std.v2 range interfaces are stable; others may not be'.  And at that point it is immediately useful.  Complete, stable std.v2 just happens when all of its components are stabilised.

On 2021-11-02 18:27, Elronnd wrote:
> On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu wrote:
>>> Not it all, std2 sounds to me like std.experimental just with a different name.
>>
>> Must have been a miscommunication on my part. The two couldn't be more different.
> 
> I don't think the concern is that they are _intended_ to be similar, but that they will end up that way.
> 
>> std.experimental:
>> - Intent is to be moved to std when ready, where it ADDS functionality
> 
> And yet, std.experimental seems to be where code goes to die. std.sumtype exists, probably only because pbackus didn't let it go into std.experimental.

This seems to presuppose I was making the argument std.experimental is good.

FWIW I fully supported and encouraged Paul to merge his work straight into std.

> std.v2 is similar in at least one respect: it does not start off stable, and will presumably get that way at some point.  At what point do we say 'std.v2 is now stable'?  Well, that's exactly the same question we ask about things in std.experimental.

The answer to the same question is radically different for the two.

1. For experimental: has the artifact and its API mature? It's a vague question.

2. For stdv2: does it cover all symbols from std? It's a very precise question.

> Here's one way it could be done: stabilize individual components of it at a time.  So, say: get rid of autodecoding and maybe the class range thing, and then say 'all std.v2 range interfaces are stable; others may not be'.  And at that point it is immediately useful.  Complete, stable std.v2 just happens when all of its components are stabilised.

I don't think there's a need for such a staggered release. Use std2alpha or whatever until all components are ported, then rename and release officially.

On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu wrote:
> Must have been a miscommunication on my part. The two couldn't be more different.

I think it was a miscommunication on my part.

I'm not concerned about adding stuff or change stuff.

Both std.experimental and std.v2 split phobos in two, that is my problem with
std.v2.



Please remove and add to phobos as much as you see fit, but don't split it.

I said it in the long post once before, but I say it again.
By the time I have explained to somebody new why D is in version 2.099 with
phobos having parts in version v2 in addition to std.experimental, which is
was pretty much DOA, the person has installed, compiled, and run "hello world"
in rust.

On Wednesday, 3 November 2021 at 16:51:43 UTC, Robert burner Schadek wrote:
> Both std.experimental and std.v2 split phobos in two, that is my problem with
> std.v2.

No.  std.experimental does not split anything.  It's extra stuff you don't need to use.

>
> Please remove and add to phobos as much as you see fit, but don't split it.
>

This statement must be hyperbole.  Obviously adding and removing from the standard library on a whim is not acceptable.

On Wednesday, 3 November 2021 at 15:02:57 UTC, Andrei Alexandrescu wrote:
> On 2021-11-02 18:27, Elronnd wrote:
>> On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu wrote:
>>>> [...]
>>>
>>> Must have been a miscommunication on my part. The two couldn't be more different.
>> 
>> I don't think the concern is that they are _intended_ to be similar, but that they will end up that way.
>> 
>>> std.experimental:
>>> - Intent is to be moved to std when ready, where it ADDS functionality
>> 
>> And yet, std.experimental seems to be where code goes to die. std.sumtype exists, probably only because pbackus didn't let it go into std.experimental.
>
> This seems to presuppose I was making the argument std.experimental is good.
>
> FWIW I fully supported and encouraged Paul to merge his work straight into std.

Likewise.

I'm going to look at the PR in detail and comment later.

On 2021-11-03 12:51, Robert burner Schadek wrote:
> On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu wrote:
>> Must have been a miscommunication on my part. The two couldn't be more different.
> 
> I think it was a miscommunication on my part.
> 
> I'm not concerned about adding stuff or change stuff.
> 
> Both std.experimental and std.v2 split phobos in two, that is my problem with
> std.v2.

There's no splitting. You get to use std or std2. New code should use std2. Old code can migrate to std2. There's gotta be two by the pigeonhole principle. I don't see how this can be done otherwise.

The situation with std.experimental is very different. There a trivial claim can be made that there's "splitting" for the simple reason what's in one is not in the other.

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

Update: the entire std.algorithm.comparison is now versionable. Took about a day. I expect others to take less based on experience accumulated.

Found a bad compiler bug exposed by versioning equal(). Noted in the text. I don't think there's a workaround.

Spoiler: the code looks passable. Further spoiler: it's not quite a basket of fruit.

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

I'm highly skeptical of making phobos 2 at this time. Maybe I'm wrong, but we discussed it not so long ago, and I tried to work on collections for it.

Problem is: it is not possible, as far as I can tell, to write a high quality collection library in D right now.

Because this is such a basic building block, I really question what phobos 2 can really achieve. The root cause of the mess that is phobos is that it is built on shaky grounds, and phobos 2 will be built on the same ground.