On Thursday, 17 June 2021 at 16:50:28 UTC, Paolo Invernizzi wrote:

size_t favoriteNumber() @safe { return 42; }

int favoriteElement(ref int[50] array) @trusted
{
    // This is memory safe because we know favoriteNumber returns 42
    return array.ptr[favoriteNumber()];
}

[...]

Yes, that's exactly my point. This can't be solved by changing the language, but it can be solved by a good code review process. So we should avoid wasting our time on language-based solutions (like Steven's proposal for @system blocks in @trusted functions), and instead focus on how to improve our code review process so that this kind of brittle @trusted code doesn't slip through.

For example, a review process that enforced the following rules would have flagged favoriteElement as problematic:

1. Every use of @trusted must be accompanied by a comment containing a proof of memory safety.
2. A memory-safety proof for @trusted code may not rely on any knowledge about other functions beyond what is implied by their signatures.

Specifically, favoriteElement violates rule (2). To bring it into compliance, we'd have to either add an assert to verify our assumption about favoriteNumber, or find a way to encode that assumption into favoriteNumber's signature (for example, with an out contract).

On Thursday, 17 June 2021 at 15:08:53 UTC, Dukc wrote:

Sure, but that is obviously not enough. Because what is being said implies that @trusted code have to assume that anything it receives that isn't pointers can be garbage and that such garbage should never lead to memory unsafety even if you know that the @trusted function never receives garbage.

My conclusion so far is that it is unrealistic to think that anyone would write code that satisfies that requirements put upon @trusted functions for a program the size of a desktop application.

It is even unrealistic to think that the average D programmer will understand what the requirements for @trusted are!

On Thursday, 17 June 2021 at 14:30:58 UTC, Steven Schveighoffer wrote:

But doesn't this mean that having even a single @safe method on an ADT class would be a liability? So you are essentially forced to define them all as @trusted?

E.g.

class A {

    this() @trusted {
        ptr = &buffer[0];
        offset = 0;
    }

    int get() @trusted { return ptr[offset]; }
    void set(int i) @trusted { this.offset = i&1; }

    /*BUG: offset was pasted in here by mistake*/
    int size()@safe{ offset=2;  return 2;}

private:
    int[2] buffer;
    int* ptr;
    int offset;
}

Since this @safe size() function could in theory mess up offset by a bug, it should not be allowed?

However if we make size() @trusted then this is perfectly ok by the requirements?

As a result, you have to make ALL methods @trusted.

On Thursday, 17 June 2021 at 17:24:27 UTC, Ola Fosheim Grøstad wrote:

Ah, I guess the problem is that someone phrased that slightly wrong. Let me try a better formulation.

Given a module module_a, if a client module module_b that imports only module_b, and contains only @safe code cannot cause memory corruption (except due to compiler/OS/hardware bugs), then and only then API of module_a is sound with regards to memory safety.

This means that a @trusted or @safe function is allowed to assume certain invariants about some types, as long as those invariants cannot be violated from @safe client code alone. This also means that @safe code that is in module_a may be able to violate memory safety. DIP1035 aims to address that.

On Thursday, 17 June 2021 at 17:49:39 UTC, Dukc wrote:

Meant: that imports only module_a

On Thursday, 17 June 2021 at 17:49:39 UTC, Dukc wrote:

So if I control module_0 and module_a depends on it, then I can assume the invariants for types in module_0 as long as module_b cannot break those invariants from @safe code?