On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:
> 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.

Tbh. the best solution would be ditching Phobos for an entirely new standard library. Like writing it from scratch and when it's stable enough then provide a way of transitioning existing code to the new standard library.

On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:
> 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.

That is an orthogonal problem. If we agreed to merge some collections library to Phobos, it could be done to Phobos 1 just as well. We don't need Phobos 2 for that.

Rather Phobos 2 lets us to discard some old design decisions we don't want to keep around anymore. Autodecoding is the best example, but not the only one. Were we simply to drop that in Phobos 1, it would be far more difficult to migrate for users.

On Friday, 5 November 2021 at 06:47:53 UTC, bauss wrote:
>
> Tbh. the best solution would be ditching Phobos for an entirely new standard library. Like writing it from scratch and when it's stable enough then provide a way of transitioning existing code to the new standard library.

Aren't you worried it would be much more difficult to finish with our manpower, and to get users to leave Phobos even then?

On Friday, 5 November 2021 at 06:47:53 UTC, bauss wrote:
> Tbh. the best solution would be ditching Phobos for an entirely new standard library. Like writing it from scratch and when it's stable enough then provide a way of transitioning existing code to the new standard library.

If it was kept smaller maybe. Meaning no xml, json, zip, zlib, digest, datetime, curl, odbc, checkedint, function, algorithms, sumtype, ranges, etc.

Move all those (same code) to a separate application layer with its own versioning.

But before doing anything like that you ought to:

1.  Go through Phobos and find all the language issues that are addressed in the Phobos code.

2. Change the language so that a new standard lib does not have to account for language weaknesses.

3. Write the standardlib in such a way that it is quite low level (everything should be meaningful in the context of embedded programming).

4. Identify interdependencies in the current Phobos library.

5. Write a set of "standard" application level libraries on top of that (streams/ranges, algorithms, compression, encryption etc), split up in such a way that there are no interdependencies (4).

It is totally doable. It is a management issue. Mostly political. Not so much to do with manpower or technicalities IMHO.

On Friday, 5 November 2021 at 09:45:49 UTC, Dukc wrote:
> On Friday, 5 November 2021 at 06:47:53 UTC, bauss wrote:
>>
>> Tbh. the best solution would be ditching Phobos for an entirely new standard library. Like writing it from scratch and when it's stable enough then provide a way of transitioning existing code to the new standard library.
>
> Aren't you worried it would be much more difficult to finish with our manpower, and to get users to leave Phobos even then?

Sure. I'm not saying it's even possible, but just that it would be the best solution.

On Friday, 5 November 2021 at 10:53:17 UTC, Ola Fosheim Grøstad wrote:
>
> 3. Write the standardlib in such a way that it is quite low level (everything should be meaningful in the context of embedded programming).
>


I think that's a wrong approach. It should provide both low-level and high-level approaches to problems.

Too much low-level is going to make it very verbose.

On 2021-11-05 2:47, bauss wrote:
> On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:
>> 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.
> 
> Tbh. the best solution would be ditching Phobos for an entirely new standard library. Like writing it from scratch and when it's stable enough then provide a way of transitioning existing code to the new standard library.

The same issues will apply to that new standard library. We thought we knew all mistakes of D1 and Phobos1, too.

On Friday, 5 November 2021 at 09:43:21 UTC, Dukc wrote:
> On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:
>> 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.
>
> That is an orthogonal problem. If we agreed to merge some collections library to Phobos, it could be done to Phobos 1 just as well. We don't need Phobos 2 for that.
>

No it is not.

The reason for which phobos v1 does not have a good set of collection have not changed, and therefore phobos v2 will not have a good set of collections.

Range have the exact same problem.

On Friday, 5 November 2021 at 12:48:01 UTC, bauss wrote:
> On Friday, 5 November 2021 at 10:53:17 UTC, Ola Fosheim Grøstad wrote:
>>
>> 3. Write the standardlib in such a way that it is quite low level (everything should be meaningful in the context of embedded programming).
>
> I think that's a wrong approach. It should provide both low-level and high-level approaches to problems.
>
> Too much low-level is going to make it very verbose.

Not really, because if you write an application (like most do), you would use the shipped supported application library layer that is on top of the core standard library. By supported I mean that it is written by the same group that is responsible for the core standard library, and that is either provided in the same archive as the compiler or in a package manager that ships with the compiler.

However, if you write wrappers for some key C-libraries you would only depend on the core standard library and would not be affected by "application support" improvements. So that way you get a very stable wrapper.