On 2010-02-05 18:59:00 -0500, Walter Bright <[email protected]> said:
Michel Fortin wrote:
So what's the plan? Should everything theoretically safe in Phobos be
@trusted to avoid complains about unnecessary checks in programs that
don't bother about safety? Or should we make things @safe and promote
them to @trusted (for performance) only after a careful review? I'm a
proponent of not making anything @trusted in Phobos until it has been
reviewed and approved by someone else than the author.
Every function in Phobos needs to be reviewed and tagged as safe,
trusted or system as appropriate.
But is it okay to label most of Phobos @safe knowing that it'll reduce
performance? I was under the impression that we would want to make most
of Phobos @trusted for performance.
Also, I'm now realizing that @safe might be difficult to add to many
templates. For instance, this template function from std.range doesn't
know if the functions it calls on the range (length, empty, popFront)
are safe or not. Labeling it @safe will make it not work with unsafe
ranges while not labeling it @safe will make it uncallable from safe
functions (and making it trusted will make it blindly trust the range),
neither of which is very compelling.
size_t walkLength(Range)(Range range, size_t upTo = size_t.max)
if (isInputRange!(Range))
{
static if (hasLength!(Range))
{
return range.length;
}
else
{
size_t result;
for (; result < upTo && !range.empty; range.popFront) ++result;
return result;
}
}
I'm starting to think that templates should inherit the @safe attribute
from the context they're instantiated in, not from where they're
defined. This would solve the above problem nicely as well as the
problem of string predicates in std.algorithm:
sort!"a < b"(array);
// whether "a < b" needs to be safe depends on the context
--
Michel Fortin
[email protected]
http://michelf.com/
