Proof of concept for v2 - NO duplication, NO `static if` hell, NO difficulty with interoperability
SeeWebsiteForEmail at erdani.org
Sun Oct 31 17:32:07 UTC 2021
On 10/31/21 12:57 PM, russhy wrote:
> 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
> 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
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