Please, can the langauge stop inferring scope and return for @trusted/@system?

Dennis dkorpel at gmail.com
Thu May 19 09:29:50 UTC 2022


On Thursday, 19 May 2022 at 07:13:05 UTC, Dukc wrote:
> Frankly, this violates the principle of least astonishment 
> pretty badly. Can't we just have a simple rule: if the function 
> is explicitly marked `@trusted` or `@system`, NO `scope` or 
> `return` attributes are inferred whatsoever?

There used to be different rules for lifetime errors in all of 
these:
- explicit `@system` functions
- `@system` by default functions (yes, [they were 
special](https://issues.dlang.org/show_bug.cgi?id=19873))
- inferred functions
- `@safe` functions
- `@trusted` functions

It was really complex and confusing, and I've worked on 
simplifying it such that all lifetime errors are safety 
violations like any other. The only exception is directly 
returning a dangling pointer to a stack variable, which is just 
an error even in @system code ([issue 
19873](https://issues.dlang.org/show_bug.cgi?id=19873)). I don't 
want to go back to more special cases, especially with the 
dip1000 by default transition which is complex enough as is.

I also don't agree with the "principle of least astonishment" 
violation. Consider this slice example:

```D
struct Slice(T)
{
     size_t length;
     private @system T* _ptr;

     // `@safe` read-only access to _ptr
     T* ptr() @trusted { return length == 0 ? null : _ptr; }
}
```

I expect the compiler to infer `return scope` for `ptr()` here.


More information about the Digitalmars-d mailing list