dcollections 1.0 and 2.0a beta released

[Bruno Medeiros]

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?

-- 
Bruno Medeiros - Software Engineer