Typical security issues in C++: why the GC isn't your enemy

[Dom DiSc]

On Monday, 23 January 2023 at 03:19:07 UTC, Siarhei Siamashka 
wrote:
> On Sunday, 22 January 2023 at 21:02:06 UTC, Dom Disc wrote:
>> The difference is only
>>
>> @trusted fn() {
>>
>> };
>>
>> vs.
>>
>> @safe fn() { @trusted {
>>
>> } };
>
> The second variant looks more verbose and more ugly to me.

That's so because a whole trusted function is an abomination.
Most of the time it should look more like this:

```d
@safe fn()
{
    // lot of safe stuff

    @trusted {
        @assert(/*systemFunc is safe to be used with param1*/);
        @assert(/*systemFunc is safe to be used with param2*/);
        systemFunc(param1, param2);
    }

    // more safe stuff

}
```

And I like that much more than

```d
@trusted fn()
{
    // lot of safe stuff - why do I need to check that manually?

    // only the two asserts have to be checked manually:
    @assert(/*systemFunc is safe to be used with param1*/);
    @assert(/*systemFunc is safe to be used with param2*/);
    systemFunc(param1, param2);

    // more safe stuff - why do I need to check that manually?

}
```

>> But what we gain is that @save/@system is then a binary 
>> attribute and not a cumbersome tri-state anymore. Everything 
>> is either safe or not.
>
> Dropping support for the @trusted function attribute even after 
> some deprecation period would be a rather annoying 
> compatibility breaking change.

Of course - it should not have been introduced to begin with.
Fixing things very late is always a pain in the ass.

> That's a high price for something that is just cosmetics.

I don't consider this pure esthetic.
It's also much easier to understand for newcommers.

But ok, I can live with the state we have now. This is more 
something for D3