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