Since neither Andrei or Walter are able to say something sensible
on these issues when asked, I apparently need to learn something
about the "consistency" of C memory safety.
I'm happy to listen to anyone who can explain this to me:
1. My understanding is that @trusted is supposed to give memory
safety escapes by providing a context which reestablish a memory
safety context on return.
Yet in this thread
http://forum.dlang.org/thread/mcik3j$153g$1...@digitalmars.com it is
stated that this paradigm is an example of «careful use of
@trusted»:
count = (() @trusted => cast(uint*) malloc(uint.sizeof))();
…arbitrary code…
(() @trusted => free(count))();
They way I see it, this is equivalent to typing a
reinterpret_casting malloc and free as memorysafe operations in
isolation, basically providing a malloc!int() and free() as
memory safe functions. But why is malloc and free not considered
safe by default then? These @trusted functions clearly cannot
prevent leaks within their own context. You would need a
@trusted-only storage class on the receiving pointer to do that
and a @trusted move type.
If this is careful use of @trusted, then I don't see the point of
having @trusted at all. What is the purpose? What is it meant to
cover? In order for @trusted to make sense in this code segment (
http://dpaste.dzfl.pl/f3d854feede9 ) I would say that the whole
class will have to be marked @trusted. Is that possible?
2. In a recent change D now has implemented "return ref", but
when I ask if this has implications for coroutines that take ref
as parameters, I get no answer. So what is the deal here? Are
coroutines banned from taking ref arguments? Will it be possible
to retain unsafe references by yielding? Since the feature is
implemented I presume there is a clear answer to this.
What is the scope of memory safety in D? Is it a lint-like
feature, or is it something to be relied upon?
