I do something similar with my error types.

I have a method called assumeOkay. It'll assert if it isn't ok.

There is also unsafeGetLiteral for slice based types.

All @system.

On Friday, August 25, 2023 3:00:08 PM MDT Guillaume Piolat via Digitalmars-d- learn wrote:
> The idea is to deliberately mark @system functions that need special scrutiny to use, regardless of their memory-safety. Function that would typically be named `assumeXXX`.
>
>
>
> ```d
> class MyEncodedThing
> {
>      Encoding encoding;
>
>      /// Unsafe cast of encoding.
>      void assumeEncoding (Encoding encoding) /* here */ @system /*
> here */
>      {
>          this.encoding = encoding;
>      }
> }
>
> char* assumeZeroTerminated(char[] str) @system
> {
>      return str.ptr;
> }
>
> ```
>
> That way, @safe code will still need to manually @trust them.

Well, if no attribute inference is involved, then @system isn't required. However, explicitly marking it @system makes it so that you won't accidentally make it @safe via later introducing attribute inference or by adding something like @safe: or @safe {} to the code. It also makes it clear that the @system is intentional rather than it being the case that no one decided to put @safe or @trusted on it.

So, it arguable is good practice to mark functions @system if they're intended to be @system rather than leaving it up to the defaults.

Either way, if the code using those functions are going to be able to use @trusted correctly, the documentation should probably be very clear about what the @system function is doing - at least if you're not in an environment where everyone is expected to look at the code itself rather than at documentation.

- Jonathan M Davis