On Friday, 8 July 2016 at 19:26:59 UTC, Andrei Alexandrescu wrote:
On 07/08/2016 02:42 PM, deadalnix wrote:
It is meaningless because sometime, you have A and B that are
both safe
on their own, but doing both is unsafe. In which case A or B
need to be
banned, but nothing allows to know which one. This isn't a
bug, this is
a failure to have a principled approach to safety.
What would be a good example? Is there a bug report for it?
For instance:
@safe
int foo(int *iPtr) {
return *iPtr;
}
@safe
int bar(int[] iSlice) {
return foo(iSlice.ptr);
}
foo assume that creating an invalid pointer is not safe, while
bar assume that .ptr is safe as it doesn't access memory. If the
slice's size is 0, that is not safe.
This is one such case where each of this operation is safe
granted some preconditions, but violate each other's
preconditions so using both is unsafe.
The position is inconsistent because the dictatorship refuses
to
compromise on mutually exclusive goals. For instance, @safe is
defined
as ensuring memory safety. But not against undefined behaviors
(in fact
Walter promote the use of UB in various situations, for
instance when it
comes to shared). You CANNOT have undefined behavior that are
defined as
being memory safe.
I agree with that. What would be a good example? Where is the
reference to Walter's promotion of UB in @safe code?
I don't have a specific reference to point to right now. However,
there have been several event of "@safe guarantee memory safety,
it doesn't protect against X" while X is undefined behavior most
of the time.
