Simplification of @trusted (page 15)

On Wednesday, 23 June 2021 at 06:25:08 UTC, Andrei Alexandrescu wrote: > Non-sequitur. The problem is there is no @system/@trusted/@safe troika for pure. It's either pure or not, no way to express (as is needed in key parts) "this function shall be trusted to be pure". Then you need to list explicitly what `pure` means in terms of allowed optimizations. Otherwise you'll end up with something that is too weak to be useful for compiler authors.

On Wednesday, 23 June 2021 at 12:32:03 UTC, Ola Fosheim Grøstad wrote: > Then you need to list explicitly what `pure` means in terms of allowed optimizations. Otherwise you'll end up with something that is too weak to be useful for compiler authors. This includes deadlock issues. If you allow access to globals you could get deadlocks that `pure` would have prevented.

On 23.06.21 12:28, jmh530 wrote: > On Wednesday, 23 June 2021 at 06:25:08 UTC, Andrei Alexandrescu wrote: >> [snip] >>> Doing things like that is why D supports @system code. >> >> Non-sequitur. The problem is there is no @system/@trusted/@safe troika for pure. It's either pure or not, no way to express (as is needed in key parts) "this function shall be trusted to be pure". >> [snip] > > Reminds me of C's restrict. It's kind of like the equivalent of trusting that you are not overlapping data. I don't believe it provides a compile-time error if you do (just run-time undefined behavior). UB is too blunt of an instrument for trusted pure though, you should just lose some guarantees on ordering and number of executions, possibly aliasing (due to memoization).

auto temp = str.toUTF32; /* Unsafe cast. Allowed because toUTF32 makes a new array and copies all the elements. */ return () @trusted { return cast(CopyTypeQualifiers!(ElementType!String, dchar)[]) temp; } ();

// SAFETY: mem::align_of() returns a non-zero usize which is then casted // to a *mut T. Therefore, `ptr` is not null and the conditions for // calling new_unchecked() are respected. unsafe { let ptr = mem::align_of::<T>() as *mut T; NonNull::new_unchecked(ptr) }

July 13, 2021

Re: Simplification of @trusted

Posted by Bruce Carneal
in reply to Per Nordlöw

Permalink

Bruce Carneal

Posted in reply to Per Nordlöw

Permalink

On Sunday, 11 July 2021 at 08:36:33 UTC, Per Nordlöw wrote:

On Wednesday, 16 June 2021 at 15:37:22 UTC, H. S. Teoh wrote:

This isn't the first time it was suggested. Way back when, it was brought up and rejected because Walter thought that @trusted blocks should be discouraged, and therefore should be ugly to write. It was extensively argued, but Walter preferred the "trusted lambda idiom", precisely because it was ugly, required effort to write, and therefore deters casual (ab)uses of @trusted.

Rust, C#, V all use

unsafe { ... }

Can we please allow

unsafe { ... }

, Walter?

It's trivial to grep for @trusted to find all possible safety violations in projects.

Localization/minimization of code that must be reviewed for basic safety is very desirable. The quiet pollution caused by a nested non-static @trusted lambda within code marked @safe is not.

IIUC, ongoing tolerance of such lambdas means that all @safe code must be grepped/reviewed or else blindly trusted. IOW, as things stand currently, @safe code bodies must be treated as @trusted until manually proven otherwise.

My preference is to move in the other direction, towards @safe checking-by-default within @trusted blocks with @system syntax to escape from there (a backwards compatible transition proposal for this with simple syntax to be discussed at July beerconf).

Forums