On Sunday, 2 March 2025 at 15:07:30 UTC, Mike Shah wrote:

I like the consistency with existing language in this proposal. User-defined attributes already work like this, as your @trustmore example shows. The language would simply have to pretend that safe, trusted and system are structs that can be constructed with a string argument.

Still, I think a standartised DDoc section would probably be a better way to do this since this is essentially just another way to write a comment.

On Sunday, 2 March 2025 at 15:07:30 UTC, Mike Shah wrote:

// Proposed syntax to also be legal
void func1() @safe("This needs to be safe as it's part of client interface"){}
void func2() @trusted("Code Reviewed by Mike Pull Request #1234567, and is trusted for reason XYZ"){}
void func3() @system("Need to make a system call..."){}

[…]

I fail to see why a comment wouldn’t suffice for @safe and @trusted.
I’d even say @safe needs nothing of that sort because it’s compiler-checked anyways.

A message next to @safe and @trusted wouldn’t ever be shown. Only @system("Can't be @trusted because …") makes sense in case a @safe function calls it. Then, the compiler could say:

Error: `@safe` function `doInnocuous` cannot call `@system` function `doDangerous`.
Note:  `doDangerous` was annotated `@system` with the following message:
       "Can't be @trusted because …"

That could be useful if the programmer can anticipate that a function is expected to be used by @safe code but can’t actually be for a non-trivial reason (let’s say a corner case). The message can then even point to a @safe-compatible alternative, similar to the message of a deprecated symbol usually does that.

I’m not sure if such a diagnostic construct needs a DIP. It’s simple enough not to cause problems, but it does occupy some design space that other proposals might have their eyes on, such as Argument-dependent Attributes (ADAs).

Considering ADAs, that could be solved by proposing a different attribute e.g. @systemBecause("reason") that wouldn’t clash. Semantically, @systemBecause would be the same as @system, only the parser knows it’s not @system(parameterName). Another option would be to step down the game and require a string literal because that can’t clash with a parameter name (an identifier).

Note that ADAs is just an example to point out that this design space is contended.

The reason C++26 added = delete("reason") is because if you call the deleted thing, you get an error message. For some things, it’s obvious why they’re deleted (e.g. the copy constructor of std::unique_ptr), but when it’s not, that error message can now include some details. It’s similar to why static_assert and deprecated can have messages. It doesn’t translate to @safe and @trusted, only to @system.