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 might have been inclined to back you on that one... that said though,
> > the real solution to that category of problem is to accept that we need
> > annotated scopes.
> > We need to have:
> >
> > @trusted {
> >    some_code;
> > }
>
> 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.


Yes, this isn't a new conversation! We've all been begging for this since literally the day it landed ;)

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.

On Sun, 25 Aug 2024 at 10:56, Timon Gehr via Digitalmars-d < 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.

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.

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.

On Saturday, 24 August 2024 at 17:10:39 UTC, Manu wrote:
> We need to have:
>
> @trusted {
>   some_code;
> }

We have:

() @trusted {
   some_code;
}();

Which works kind of the same, beside it's ugly as hell.
Until we have real trusted blocks, I use this (heavily).

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.

On Sun, 25 Aug 2024 at 19:26, Dom DiSc via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Saturday, 24 August 2024 at 17:10:39 UTC, Manu wrote:
> > We need to have:
> >
> > @trusted {
> >   some_code;
> > }
>
> We have:
>
> () @trusted {
>     some_code;
> }();
>
> Which works kind of the same, beside it's ugly as hell. Until we have real trusted blocks, I use this (heavily).



..."kind of the same"


int normal_scope(int x, int y)
{
    int t;

    // normal scope
    {
        t = x + y;
    }

    return t;
}

        assume  CS:.text._D7example12normal_scopeFiiZi
                push    RBP
                mov     RBP,RSP
                sub     RSP,020h
                mov     -010h[RBP],EDI
                mov     -8[RBP],ESI
                mov     dword ptr -018h[RBP],0
                mov     EAX,-8[RBP]
                add     EAX,-010h[RBP]
                mov     -018h[RBP],EAX
                leave
                ret



int stupid_hack(int x, int y)
{
    int t;

    // stupid hack
    () @trusted {
        t = x + y;
    }();

    return t;
}


        assume  CS:.text._D7example11stupid_hackFiiZi
                push    RBP
                mov     RBP,RSP
                sub     RSP,020h
                mov     -010h[RBP],EDI
                mov     -8[RBP],ESI
                mov     dword ptr -018h[RBP],0
                mov     RDI,RBP
                call    qword ptr pure nothrow @nogc @trusted void
example.stupid_hack(int, int).__lambda4()@GOTPCREL[RIP]
                mov     EAX,-018h[RBP]
                leave
                ret
        assume  CS:.text.pure nothrow @nogc @trusted void
example.stupid_hack(int, int).__lambda4()
pure nothrow @nogc @trusted void example.stupid_hack(int, int).__lambda4():
                push    RBP
                mov     RBP,RSP
                sub     RSP,010h
                mov     -8[RBP],RDI
                mov     RAX,-8[RBP]
                mov     ECX,-8[RAX]
                add     ECX,-010h[RAX]
                mov     -018h[RAX],ECX
                leave
                ret
                add     [RAX],AL


I hope we can agree that this is definitely not 'kind of the same'...

And that's to say nothing about the damage it causes to the debug info, and the ability to breakpoint and step through the code in a sane way. Completely unacceptable hack. I won't give this pattern the dignity of my fingertips approval under any circumstances. It should not be legitimised.

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?

On Sunday, 25 August 2024 at 10:28:57 UTC, Manu wrote:
> On Sun, 25 Aug 2024 at 19:26, Dom DiSc via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Saturday, 24 August 2024 at 17:10:39 UTC, Manu wrote:
> I hope we can agree that this is definitely not 'kind of the same'...
>
> And that's to say nothing about the damage it causes to the debug info, and the ability to breakpoint and step through the code in a sane way. Completely unacceptable hack. I won't give this pattern the dignity of my fingertips approval under any circumstances. It should not be legitimised.

was that with DMD without optimisations, or LDC with optimisations?
If this is the former, that's probably that's to be expected.