dcollections 1.0 and 2.0a beta released

[Steven Schveighoffer]

On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros  
<brunodomedeiros+spam at com.gmail> wrote:

> On 24/05/2010 16:45, Andrei Alexandrescu wrote:
>>> In the past I have built a C++ library that abstracted features of
>>> the OS. My goal was to make it possible to dynamically load a module
>>> that abstracted things like setting the IP address of a network
>>> interface. My modules used std::string instead of char * to lookup
>>> services to get objects that implement the interface. Big mistake. On
>>> a later version of the standard C++ runtime, the private
>>> implementation of std::string changed, so the dynamically loaded
>>> libraries crashed horribly. No change in string's interface, just the
>>> private stuff changed, but because it's a template, the code that
>>> uses it necessarily has to be aware of it. We ended up ditching the
>>> standard C++ library's version of string, and used STLPort so we
>>> could control the library.
>>>
>>> I envision this same sort of problem would be likely with D
>>> collection objects that were not used via interfaces.
>>
>> I see no problem retrofitting a no-interface container into a formal
>> interface if so needed.
>
>
> I don't understand this discussion: isn't the reason above pretty much a  
> dead-on hard requirement for the collections to have interfaces?
> Something like, for example, an interface version of the range traits?

Only if you wish to have binary compatibility with dynamic libs.  Such a  
thing isn't likely today since dynamic libs aren't very well supported in  
D, and even phobos or dcollections isn't a dynamic lib.

And I have specifically decided not to use interfaces with ranges because  
that makes them reference types.  Ranges work well as value types, but not  
well as reference types.  Therefore, to use dcollections as interfaces,  
you must not require the range traits.

-Steve