On Sun, 25 Aug 2024 at 13:21, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 8/25/24 04:04, Manu wrote:
> On Sun, 25 Aug 2024 at 10:56, Timon Gehr via Digitalmars-d <digitalmars-
> d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     On 8/24/24 19:10, Manu wrote:
>      >
>      >     Some years back, I got into a terrific disagreement with everyone
>      >     else in the D
>      >     community when I wanted C declarations to default to @trusted :-/
>      >
>      >
>      > I might have been inclined to back you on that one...
>
>     Well, you'd have been wrong. Just remove @safe at that point.
>
>
> Well I think the proper solution is to allow the user to declare unsafe
> (ie, @trusted) code blocks, and make unsafe calls from within those
> blocks, which would include calls to C code.

`@trusted` does not mean unsafe. `@trusted` means memory safe but not
automatically checked. Some `extern(C)` functions can be marked
`@trusted`, it's just a really bad default as memory-unsafe interfaces
abound in C.

Anyway, I fully agree there would be more ergonomic ways to design those
features.

Yeah the 'trusted' terminology doesn't actually map well to the operation that the programmer usually wants to perform, which is "I am about to do something unsafe, but I'm trying to assert confidence that I knew what I was doing".
An 'unsafe' scope is almost always what the user wants. @trusted sits awkwardly conceptually; I see provably-safe and unsafe, and that's it. Any middling is a programmers effort to make use of unsafe machinery and assert that they thought they did it right; while leaving a trail that you can search for in the code.