On Wednesday, 25 February 2015 at 07:07:00 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 25 February 2015 at 00:12:41 UTC, anonymous wrote:
[...]
That sounds more attractive than the provided example, but the
right thing to do is to establish proper encapsulation. That
means you need a protection level that is stronger than
"private" that restricts "unsafe state" to a @trusted vetted
construct. Like unique_ptr informally does in C++.
I'm not knowledgeable enough to agree or disagree here.
But why is malloc and free not considered safe by default
then?
Well, because they aren't.
So that should change?
We can't make malloc and free actually memory-safe, can we? We
must not mark public unsafe functions @safe/@trusted.
You mean outside RCArray, iff RCArray as a whole is manually
verified? But that would surely mean that the @trusted region
is RCArray and neither the constructor or malloc/free?
RCArray as a whole is the actually trusted region, yes, since it
must be manually verified that RCArray.array isn't leaked. But
you can't mark it @trusted, because E may be unsafe.
The @trusted malloc/free dance is a mean hack to solve a problem.
There may be other solutions that don't require breaking
@trusted. Those may be better.
And that assumes strong typing, which D currently does not
provide. Without strong typing it will be very difficult for
the compiler to infer anything across compilation units.
I don't follow.
