Re: Cool pattern or tragic?
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.
Re: Cool pattern or tragic?
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.
Re: Cool pattern or tragic?
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
Re: Cool pattern or tragic?
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.
