Expand std.containers

[crazymonkyyy]

trafficstars

Description

Std containers is... inadequate; which doesn't make much sense given the more palatable templates compared to c++ and the comfyness of having a definition of ranges to aim for.

What are rough milestones of this project?

1. Make a dozen or so, formal specification and example code for some criticism.
2. Purge the list of ideas that won't actually work in practice, and smooth out the user experience.
3. Get 100% compliant with the d style guide and documentation standards to submit it to the std.

How does this project help the D community?

Good data structures shouldn't be a weakness here; but quite frankly they are. Data structure with op overloads and range like standards can be zero overhead abstractions that compile down roughly to the same speed as well written c code, without the same maintenance and user knowledge/work that would entail. Is that not your goal here?

Recommended skills

• Data oriented design.
• Rough idea what modern processors are doing.
• Templates.

Rating

Medium

Project Type

Core development

What can students expect to get out of doing this project?

Experience to contributing to a high standard codebase. Experience with generic programming. Being involved with a highly passionate and experience community.

Point of Contact/Potential Mentors

@crazymonkyyy @edi33416

References

https://issues.dlang.org/show_bug.cgi?id=20801

[wilzbach]

Thanks a lot for your idea, but I'm not sure whether this is a good project as Phobos can't be easily modified without breaking backwards compatibly.

A modern approach to containers in D can be found here: https://github.com/dlang-community/containers

It was planned to integrate this project into druntime, but unfortunately this effort stalled.

[crazymonkyyy]

I'm more then a little confused by the repeated comments that gc this or gc that effects this. If you allocate a large array only a very very bad gc trying to do something far to clever for its own good could screw it up and make your iteration thru it slow which given that pointers work d isnt doing that. Its a question of how you iterate thru it and manage the memory there a one time cost to allocate something big you leave alive for a long period of time is fine.

[wilzbach]

There are many discussions about this, but essentially the point of a new containers library is to give people the option to choose the best-fitting allocator for their respective data.

[crazymonkyyy]

Not to have good data containers?

I feel like your grouping my poor esteem for std.containers with the goals std.experimental.allocators; I'm not really interesting in custom allocators.

[wilzbach]

Well, my point was that one can't just touch the existing std.containers due to code breakage. Phobos is essentially frozen due to this problem and that's why one needs to start with a v2. However, such a v2 would need to be usable within @nogc.

[Hackerpilot]

Customizing the allocator is a very important step in optimizing the way that a container actually performs in the real world.

[crazymonkyyy]

Surely thats only true if it has frequent allocations; and if it has frequent allocations its cough a bad data structure.

Big data belongs in big well organized arrays