October 27

On Thursday, 27 October 2022 at 17:39:14 UTC, Quirin Schroll wrote:


On Wednesday, 26 October 2022 at 20:24:38 UTC, tsbockman wrote:


A @safe function is guaranteed by the compiler to be memory safe to call from other @safe code with (almost) any possible arguments and under (almost) any circumstances.

A @trusted function is guaranteed by its author to be memory safe to call from other @safe code with (almost) any possible arguments and under (almost) any circumstances.

The “(almost)” should be absent. If you mean something other than compiler bugs, please tell us.

In practice, @safe code depends upon a guard page to catch null pointer dereferences. If a struct field or static array element is at a sufficiently large offset from the null pointer, this can theoretically result in a silent buffer overrun. As far as I can tell, this is not considered a bug, but rather a reasonable trade-off for improved performance.

Also, doing anything at all is officially undefined behavior after a failed assertion. This is, again, theoretically problematic because debug builds may call user code to prepare or log the AssertError.

There are probably other obscure cases like these, as well, which @safe and @trusted functions are not responsible for handling correctly.


I agree with the characterization of @safe and @system. For @trusted functions, there’s something more to say:

  • Narrowly accessible ones (e.g. private (in a small module), local functions, immediately executed lambdas) can have a @system interface, but their surroundings can be trusted to use the function correctly.

My characterization agrees with the language spec, yours does not. You are essentially redefining @trusted to mean "ignore memory any memory safety issues here", instead of what it is actually intended to mean, "trust me, this is actually memory safe".

October 27
On 10/27/2022 2:36 AM, German Diago wrote:
> As a person who has used D but not extensively, I was suprised of type[] vs type[N] behavior all the time. I agree that [1, 2, 3] should allocate in the stack but I am not sure how much code that could break? For example, if before it was on the heap, what happens with this now?

You'll get an error on [1]

> int [] func() {
>    // Allocated in the stack, I presume that not safe, should add .dup?
>    int[] v  = [1, 2, 3];
>    return v;  [1]
> }
> How it should work?

Add .dup for those that need the array to survive the function.

October 28
On Thursday, 27 October 2022 at 00:57:47 UTC, Walter Bright wrote:
>     [1,2,3] is always allocated on the stack

Why isnt this an immutable constant just like a string literal?
1 2 3 4
Next ›   Last »