On Sunday, 25 August 2024 at 11:40:06 UTC, Manu wrote:
> On Sun, 25 Aug 2024 at 21:31, Paolo Invernizzi via
> Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Sunday, 25 August 2024 at 10:32:31 UTC, Manu wrote:
>> > On Sun, 25 Aug 2024 at 19:56, Paolo Invernizzi via
>> > Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>> >
>> >> On Saturday, 24 August 2024 at 17:43:38 UTC, Manu wrote:
>> >> > On Sun, 25 Aug 2024 at 03:31, Richard (Rikki) Andrew
>> >> > Cattermole via Digitalmars-d
>> >> > <digitalmars-d@puremagic.com> wrote:
>> >> >
>> >> >> On 25/08/2024 5:10 AM, Manu wrote:
>> >> >> > [...]
>> >> >>
>> >> >> I've been considering something along these lines.
>> >> >>
>> >> >> Specifically, ``@trusted`` does not mean the entire body
>> >> >> shouldn't be verified. It just means that you are going
>> >> >> to do something naughty that needs looking at.
>> >> >>
>> >> >> So you need annotated scopes inside of it, to do the
>> >> >> naughty thing.
>> >>
>> >> Just wrote a trusted function and call it: that's the sane
>> >> way to do it and respect code reviewer hard job.
>> >
>> >
>> > ...so, because I'm going to make one single unsafe function
>> > call inside of some function, I should eject all other
>> > related or unrelated safety checks for the entire
>> > surrounding context?
>>
>> No, you should isolate the unsafe part of code into a
>> function, explain why it’s unsafe, the intent of the code, the
>> expected parameter values and the expected returns, so that
>> reviewer can check that the interface is really memory safe.
>>
>> Then call this extremely simple function from the rest of safe
>> code safe code.
>>
>>
> So, this then:
>
> extern(C) int myUnsafeFunction(int x, int y);
>
> @trusted int myPointlessWrapper(int x, int y)
> {
>   return  myUnsafeFunction (x, y);
> }
>
> @safe mySuperSafeFunction(...)
> {
>    //... lots of code
>
>   int r = myPointlessWrapper(arg1, arg2);
>
>   //... lots of code
> }
>
> Brilliant.

That’s sidestepping the problem from your side: there’s no
explanation why myUnsafeFunction has an unsafe interface, under
what condition it’s unsafe, and what it’s supposed to do. Neither
any check that it’s parameters are valid and they are not turning
into memory unsafety.

A reviewer for sure will ask you to add that information and
assurance about memory safety of calling myUnsadeFunction

If the extern(C) function is intese memory safe, there should be
a way to mark the declaration @safe, also with importC, and there
we can reason about a solution.