• Joseph Rushton Wakeling (12/12) Nov 06 2012 Hello all,
• deadalnix (3/14) Nov 06 2012 You are not alone. You have my full psychological support.
• H. S. Teoh (6/17) Nov 06 2012 Ditto. If it can be done in Phobos, it should be in Phobos.
• Jesse Phillips (9/23) Nov 06 2012 dcollections is Boost and the author fully supports moving

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

Hello all,

Very naive question about dcollections 2.0 and std.container -- what are the 
reasons why dcollections has had to be developed as a standalone library, and 
what's in the way of incorporating that functionality into Phobos?

I have some potential use-cases where some of the not-in-Phobos stuff (e.g. 
sets) might be a good solution.  It'd clearly be much nicer to be able to rely 
purely on the standard library instead of something outside.  So, if there are 
some trivial things that can be done to get code transferred (e.g. if it's just 
a matter of time that people don't have), it'd be nice to know, in case I can
do 
something to assist.

Thanks & best wishes,

     -- Joe

deadalnix <deadalnix gmail.com> writes:

Le 06/11/2012 15:10, Joseph Rushton Wakeling a écrit :
 Hello all,

 Very naive question about dcollections 2.0 and std.container -- what are
 the reasons why dcollections has had to be developed as a standalone
 library, and what's in the way of incorporating that functionality into
 Phobos?

Allocator design.

 I have some potential use-cases where some of the not-in-Phobos stuff
 (e.g. sets) might be a good solution. It'd clearly be much nicer to be
 able to rely purely on the standard library instead of something
 outside. So, if there are some trivial things that can be done to get
 code transferred (e.g. if it's just a matter of time that people don't
 have), it'd be nice to know, in case I can do something to assist.

You are not alone. You have my full psychological support.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Tue, Nov 06, 2012 at 03:54:21PM +0100, deadalnix wrote:
 Le 06/11/2012 15:10, Joseph Rushton Wakeling a écrit :

[...]
I have some potential use-cases where some of the not-in-Phobos stuff
(e.g. sets) might be a good solution. It'd clearly be much nicer to
be able to rely purely on the standard library instead of something
outside. So, if there are some trivial things that can be done to get
code transferred (e.g. if it's just a matter of time that people
don't have), it'd be nice to know, in case I can do something to
assist.

 
 You are not alone. You have my full psychological support.

Ditto.  If it can be done in Phobos, it should be in Phobos.


T

-- 
"You are a very disagreeable person." "NO."

"Jesse Phillips" <Jessekphillips+D gmail.com> writes:

On Tuesday, 6 November 2012 at 14:10:35 UTC, Joseph Rushton 
Wakeling wrote:
 Hello all,

 Very naive question about dcollections 2.0 and std.container -- 
 what are the reasons why dcollections has had to be developed 
 as a standalone library, and what's in the way of incorporating 
 that functionality into Phobos?

 I have some potential use-cases where some of the not-in-Phobos 
 stuff (e.g. sets) might be a good solution.  It'd clearly be 
 much nicer to be able to rely purely on the standard library 
 instead of something outside.  So, if there are some trivial 
 things that can be done to get code transferred (e.g. if it's 
 just a matter of time that people don't have), it'd be nice to 
 know, in case I can do something to assist.

 Thanks & best wishes,

     -- Joe

dcollections is Boost and the author fully supports moving 
anything into Phobos, several existing came from dcollections.

The design of dcollections is at odds with the intended design of 
std.collections. I believe it was Cursor vs Range. And much of 
std.collections is waiting on finalization of what custom 
allocators will look like.

... seems dsource is barfing...