@safe inference fundamentally broken
Timon Gehr via Digitalmars-d
digitalmars-d at puremagic.com
Thu Jun 5 11:30:49 PDT 2014
On 06/05/2014 08:09 PM, Steven Schveighoffer wrote:
>
> A quick example:
>
> T[] getBuf(T)() @safe
> {
> T[100] ret;
> auto r = ret[];
> return r;
> }
>
> void main() @safe
> {
> auto buf = getBuf!int();
> }
>
> Note, the above compiles. An interesting thing here is that we have explicitly marked getBuf as @safe. So what if we want to remove that? It STILL compiles, because the compiler infers @safety!
AFAIK it's a well known problem.
>
> This situation is very bad. I personally think that we need to make
> slicing a stack-allocated array INVALID in @safe code,
This issue is not a fundamental problem with @safe, nor is it a matter
of personal opinion, this is simply a compiler bug.
> and not let that
> code be inferred safe. We have already demonstrated an easy way to make
> an internal delegate that can be @trusted for one line. That should be
> used to work around this limitation.
>
> I propose that we start migrating towards making slicing of stack data
> un- at safe, first by making it a warning, enabled with -w. Then making it
> an error.
>
> Thoughts?
The fundamental issue seems to lie in methodology and it is that @safe
is approximated by the DMD implementation from the wrong side. Instead
of gradually banning usage of more and more constructs in @safe, the
implementation should have started out with not allowing any constructs
in @safe code and then should have gradually allowed more and more
manually verified to be memory safe constructs.
More information about the Digitalmars-d
mailing list