Michel Fortin wrote:
On 2009-11-15 00:09:43 -0500, "Steven Schveighoffer"
<schvei...@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 n...@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
