D library projects

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-11-15 00:09:43 -0500, "Steven Schveighoffer" 
> <schveiguy at yahoo.com> said:
> 
>> I agree -- it should be possible with the metaprogramming power of
>> D to  allow for the user to choose his weapon -- power and speed
>> vs. safe.  I  think simplicity is a given.
>> 
>> For example, it could be a version statement that decides whether 
>> ranges  of a container do runtime checks for safety.
> 
> Interesting, although you'll probably want better granularity than a
>  version statement. If your containers are going to be used with
> SafeD perhaps you'll want a safe and an unsafe variant of some
> accessor functions (one with bound checks being called for safe code,
> the other without).

Here's the current proposal as distilled from the recent newsgroup
comments. I think Michal Minich made a very good point here:

===============================
> I think there are two cases:
> 
> User would want max performance from a some library, but he does not 
> care about performance. User should have the right to override 
> intentions of library writer, making his code less safe, to achieve 
> speed. Compiler flag -unsafe (or -unsafe-no-bounds-checking) should
> do this. The user will know that he is *overriding* the original
> safety to lower level.
> 
> Also, when a library writer wants his code to appeal and be usable to
>  most users, he should mark it @safe or @trusted. But in situation,
> when he knows that safe code would be always bounds-checked (there is
> no -unsafe compiler switch), he may rather mark his code @trusted,
> even if it would be safe, in order to appeal to user that don't want
> slow (bounds-checked) library. If the library writer knows that users
> can override safety (bounds-checking), he would not hesitate to use
> @safe where appropriate.
> 
> the -unsafe-no-bounds-checking flag is essential for properly working
> of safeness in D.
===============================

There were arguments to the same effect, but the above brings an 
original insight into the psychological and social aspects of the matter.

So I think a good solution is:

a) Have -release KEEP bounds checking for @safe functions, and REMOVE 
them for the others. We may consider that bounds checking in non- at safe 
functions are done with assert().

b) Define a new flag -no-bounds-checking that allows bounds checking 
removal even for @safe functions.

>> I think shoehorning containers that are graph based into value
>> types might  be a little strenuous.  All the builtin D container
>> types are essentially  reference types (arrays are not exactly
>> reference types but behave mostly  like reference types), I don't
>> see why we should change that.
>> 
>> Making them classes allows for interfaces which helps allow runtime
>>  decisions for things like copying data between containers that are
>> of different types.  See dcollections and how easy it is to copy
>> data from  one type to another.
> 
> I'm of the same opinion.

I couldn't find the details on copying. How does dcollections solve it? 
It's a double dispatch issue.

> That said, I'm wondering if the container 
> classes shouldn't also be made final (unlike dcollections). Being 
> classes would make them easy to pass as interfaces, but them being
> final would help skip the virtual calls whenever you don't pass them
> as interfaces.

Sounds nice.

Andrei