• Guillaume Piolat (20/20) Aug 25 2023 The idea is to deliberately mark @system functions that need
• Richard (Rikki) Andrew Cattermole (4/4) Aug 25 2023 I do something similar with my error types.
• Jonathan M Davis (16/36) Aug 25 2023 Well, if no attribute inference is involved, then @system isn't required...
• user1234 (5/25) Aug 26 2023 I think it's smart for `assumeZeroTerminated` because you cannot
• cc (7/12) Sep 24 2023 I basically wanted some kind of functionality similar to this but

Guillaume Piolat <first.name gmail.com> writes:

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.

"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

user1234 <user1234 12.de> writes:

On Friday, 25 August 2023 at 21:00:08 UTC, Guillaume Piolat 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.

I think it's smart for `assumeZeroTerminated` because you cannot 
use assertions or contracts to verify that.

I'd like to think the same for `assumeEncoding` but actually I 
dont see where is the unsafe cast.

cc <cc nevernet.com> writes:

On Friday, 25 August 2023 at 21:00:08 UTC, Guillaume Piolat 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`.
 ...
 That way,  safe code will still need to manually  trust them.

I basically wanted some kind of functionality similar to this but 
with regards to the GC.  Like some way to annotate a function as 
 WillAllocate or something, and forbid calling it unless the 
caller function explicitly acknowledged the allocation (without 
having to wrap everything in  nogc).  Just for fun I experimented 
with a locking GC that used the struct/dtor model to open/re-lock.