On 07/11/2016 01:50 PM, deadalnix wrote:
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);
}
Here bar should not pass the @safe test because it may produce a
non-dereferenceable pointer. Consider:
@safe int[] baz(int[] a) { return bar(a[$ .. $]; }
It is legal (and safe) to take an empty slice at the end of an array.
Following the call, bar serves foo an invalid pointer that shan't be
dereferenced.
I added https://issues.dlang.org/show_bug.cgi?id=16266. It looks to me
like a corner case rather than an illustration of a systemic issue.
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.
"Don't do the crime if you can't do the time."
Andrei
