On Wednesday, September 14, 2011 09:57 Steven Schveighoffer wrote: > On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr <[email protected]> wrote: > > On 09/14/2011 04:08 PM, Robert McGinley wrote: > >> Hey all, > >> Mostly as an exercise I'm considering writing an ArrayList, AVL tree, > >> and possible other standard data structures in D. I have two questions. > >> 1.) If completed should I send these around for review and inclusion or > >> do they not belong in phobos? > >> 2.) If I'm working on including these in phobos should I put them in > >> container.d (that has RedBlack Trees and a Singlelinked List) or is > >> there a better location? > >> Rob > > > > As far as I know, the reason why std.container is not under active > > development, is that phobos does not have an allocator abstraction yet. > > As soon as there is one, the module will probably undergo some breaking > > changes. But I think the more well implemented standard data structures > > there are in Phobos, the better. I think as soon as the standard > > allocator interface is settled on, your efforts will be welcome. Steve > > can probably answer your question better though. > > Certainly more containers are welcome. > > The review for getting things into phobos is done via github. You do not > need write permission to generate a pull request. Yes, they should all be > put into std.container for now.
That depends on the scope of the changes. If they're big enough or complicated enough, then they'd need to go in the review queue. With new containers, I don't know whether that's necessary or not. They're potentially large pieces of functionality, but much of their API is already stipulated by std.container, so not as thorough a review is necessary as might otherwise be the case. Simpler containers may not really need a formal review in the newsgroup, but if a particularly complicated container were being added to Phobos, then it would probably merit a more thorough review than you'd get via pull requests. It is a bit of a fuzzy area though. - Jonathan M Davis
