On Monday, 11 July 2016 at 18:00:20 UTC, Steven Schveighoffer
wrote:
On 7/11/16 1: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);
}
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.
That was reported and being worked on:
https://github.com/dlang/dmd/pull/5860
-Steve
Alright, but keep in mind that is an example, not the actual
problem I'm talking about. There are many reasonable way to make
the example above safe: disallow dereferencing pointers from
unknown source, do a bound check on .ptr, disallow .ptr
altogether and much more.
The root problem is that "@safe guarantee memory safety and if it
doesn't it is a bug" provides no information as to what is the
bug here and no actionable items as to how to fix it, or even as
to what needs fixing.
