Proof of concept for v2 - NO duplication, NO `static if` hell, NO difficulty with interoperability

Andrei Alexandrescu SeeWebsiteForEmail at
Sun Oct 31 17:32:07 UTC 2021

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 
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)
> (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.

More information about the Digitalmars-d mailing list