https://github.com/dlang/phobos/pull/8309

Destroy!

Is there a new management philosophy? I.e. so there's a reason to think the stories of std.expiermental hell airnt going to repeat?

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

Don't destroy - embrace!!!

On Sunday, 31 October 2021 at 08:37:58 UTC, Imperatorn wrote:
> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>> https://github.com/dlang/phobos/pull/8309
>>
>> Destroy!
>
> Don't destroy - embrace!!!

Embrace - Extend - Extinguish

On Sunday, 31 October 2021 at 11:42:47 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 31 October 2021 at 08:37:58 UTC, Imperatorn wrote:
>> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/phobos/pull/8309
>>>
>>> Destroy!
>>
>> Don't destroy - embrace!!!
>
> Embrace - Extend - Extinguish

Lol, YES!!!

On 10/31/21 12:11 AM, monkyyy wrote:
> Is there a new management philosophy? I.e. so there's a reason to think the stories of std.expiermental hell airnt going to repeat?

Thanks for asking this, forgot to mention that aspect.

The approach here is incremental release - at an extreme the PR could be merged right now and v2 become usable albeit with very few amenities - a few range functions and mismatch(). Whatever we didn't port to v2 yet will simply be absent, as opposed to working the wrong way.

Mistake

Multiple version of the same code can't coexist in the same codebase, it solve NOTHING other than inflating the STD with versions nobody will care

For V2 i personally envision a complete rewrite with clear goals in mind

Just adding a v2 for the sake of having v2 will only bring confusion without real long term goals/benefits, downsides outweighs the upsides


What's the long term goal? what problem v2 will solve?


Before any of that, i suggest finishing the allocator API story, then we can move forward in designing a v2 that focus on building a pragmatic and evolving STD that actually solve real world issues


Then se can have a SET of modules that can help solve real world issues

std.mem (allocators and stuff)
std.collections (data structures)
std.net (http/sockets/websockets)
std.utils (everything that can be reused for other modules)

Let's focus on tangible scenarios


And what about portable code?

WASM's rocket is about to lift off, will we miss it because we focused on versioning ``AnotherWayOfDoingThisWithTemplateMixinV2AndV3CompatibleBtw``

On 10/31/21 12:57 PM, russhy wrote:
> Mistake
> 
> Multiple version of the same code can't coexist in the same codebase, it solve NOTHING other than inflating the STD with versions nobody will care

We don't have the resources to do maintenance naively, so we need to look at out-of-the-box solutions that leverage the power of the D language. The assertions that multiple versions can't coexist in the same codebase comes straight from within the box.

> For V2 i personally envision a complete rewrite with clear goals in mind

The problem with forum discussions is that folks without a stake get to envision things that others are to work on. (I don't know what github used IDs various folks have, so I'm saying this in general.) The most important is the take of folks who have a stake in it and a track record, such as (looking at the contributors since 2019 at https://github.com/dlang/phobos/graphs/contributors?from=2019-01-01&to=2021-10-31&type=c) berni44, n8sh, ibuclaw, MoonlightSentinel and other heavy-hitters. And of course Razvan, the maintainer.

A complete rewrite is probably among the more naive choices, and assumes v2 will be perfect so it will need no breaking revisions on its own. I think that doesn't scale at all. Also working on all goals at the same time (autodecoding AND gc AND safety AND nicer ranges AND unify druntime+phobos AND library strings AND various improvements AND everyone's little list AND...) all but guarantees a never-ending Sisyphean task.

> Just adding a v2 for the sake of having v2 will only bring confusion without real long term goals/benefits, downsides outweighs the upsides
> 
> 
> What's the long term goal? what problem v2 will solve?

I'd say if we get rid of autodecoding that would be a solid release attainable in good time. It would also provide a model for all future evolution - v3, v4, ...

> Before any of that, i suggest finishing the allocator API story, then we can move forward in designing a v2 that focus on building a pragmatic and evolving STD that actually solve real world issues

This is vague. You are implying currently Phobos does not solve real world issues which is factually false.

> Then se can have a SET of modules that can help solve real world issues
> 
> std.mem (allocators and stuff)
> std.collections (data structures)
> std.net (http/sockets/websockets)
> std.utils (everything that can be reused for other modules)
> 
> Let's focus on tangible scenarios
> 
> 
> And what about portable code?
> 
> WASM's rocket is about to lift off, will we miss it because we focused on versioning ``AnotherWayOfDoingThisWithTemplateMixinV2AndV3CompatibleBtw``

Instead of seeing one compete with the other, I see versioning as opening opportunities and taking us out of the current stalemate.

On 10/31/21 1:32 PM, Andrei Alexandrescu wrote:
> And of course Razvan, the maintainer.

And obviously Atila, sorry for forgetting to mention.

On Sunday, 31 October 2021 at 17:32:07 UTC, Andrei Alexandrescu wrote:
> The problem with forum discussions is that folks without a stake get to envision things that others are to work on.

That's shifting the focus in a non-constructive manner. Obviously a forum discussion is primarily about getting feedback from end-users. That should not be considered to be «a problem». You need to ground the vision in concerns that end-users have.

Assuming that end-users matters, I'd say that for end-users having a small and stable standard library that focus on interfacing and basic I/O is preferable to a larger standard lib that keeps changing.