January 23
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. Also wouldn't it require an extra level of indentation if properly formatted?

> 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. That's a high price for something that is just cosmetics.

Also how do you imagine writing future code that is compatible with both the most recent versions of D compilers and also with GDC 12 (frontend version 2.100)? GDC 12 is included in Ubuntu 22.04 LTS and will be relevant for a very long time.
January 23
On 1/22/23 22:02, Dom Disc wrote:
> 
>> - Unknown scope of _actual_ `@trusted`, you will have to manually check _`@safe`_ code as well, and a priori you will have no idea how much of it you have to check (this part is terrible).
> 
> Why is this terrible? In worst case you have to check exactly as much code manually as you do today. But in most cases you have to check much less.

It's terrible for the reason I pointed out. It's not modular. A priori _you don't know how much_ code you have to check, you just know that you have to check _some_ `@safe` code, because if you check the `@trusted` lambdas on their own they cannot pass muster.

Officially you only have to check `@trusted` code. However, if you do that, typically all you learn is that the `@trusted` code is bad because it has an unsafe interface...
January 23

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:

@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

@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

January 23

On Monday, 23 January 2023 at 16:31:01 UTC, Dom DiSc wrote:

>

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

@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

}

Should be:

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

   fghn(param1, param2);

   // more safe stuff
}

@trusted fghn(p1, p2)
{
   assert(...);
   assert(...);
   systemFunc(p1, p2);
}
1 2 3 4 5 6 7 8 9 10 11
Next ›   Last »