Suggestion: New attribute for functions without any memory safety invariants

[Plecra]

See microsoft/windows-rs#1506 for how this would be useful in the Rust bindings.

Plenty of windows' APIs cant possibly break memory safety, as they check all of their invariants internally and error out if there's any problem. For example, GetStdHandle can be safely (as defined by Rust) called at any time. However, the generated bindings must pessimistically include the unsafe attribute:

windows::Win32::System::Console::GetStdHandle

pub unsafe fn GetStdHandle(nstdhandle: STD_HANDLE) -> Result<HANDLE>

Outside of the Rust ecosystem, it is generally useful to be able to recognize these "encapsulated" APIs. They can be called with predictable effects with much less scrutiny over their documentation.

A safe attribute could trivially be added to checked handle-based APIs like GetStdHandle, but I would also hope that we'd add them to APIs with enough type information to uphold pointer invariants etc.

[riverar]

I'm not sure how metadata could attribute APIs as "safe" and somehow make that work across Ecmascript, C++, C#, Rust, Dart, Zig, Beef, etc. It may be useful to figure out what "safe" means across all these languages and come up with more granular set of common attributes we could apply. (For example, we could mark an API as [DoesX] and [DoesntDoY].) Projection authors can then decide if that meets their definition of "safe".

The metadata team is currently focused on basic API issues so I don't see this happening anytime soon. Will close this for now but feel free to continue the discussion/propose something a bit more actionable.

[Plecra]

Sure thing :) I can see why you wouldn't be in a hurry to make a design for this. I'd say there's a pretty strong middle ground in each of the languages' needs though! I'm going to pop a few notes here since I doubt I'll return to this soon either.

I'd want to explore a [WithEffects(...)] attribute which would whitelist the parts of the environment that can be touched by a function. Everything without this annotation would still implicitly access all side effects, but it'd let us fully describe the behaviour of the APIs we manage to document with it. (to elaborate on this: DoesX isn't helpful because we have to assume that any unannotated function also DoesX, and DoesntDoX is similarly unhelpful because we can't know if it is doing some effect that a projection doesn't recognize. We need to explicitly start from an empty set of effects)

GetStdHandle, for example, would only need to use the effect ReadEnvironment and could be annotated [WithEffects(ReadEnvironment)]. Anything that expects to dereference user-provided pointers on the other hand, like ReadFile, would have a DereferencePointer effect. Rust's projection can whitelist ReadEnvironment as safe, but not DereferencePointer.

For forwards/backwards compatibility we'd also want to think about subtyping between effects. In the future we might want ReadEnvironment to also give permission for a more specific ReadConsoleEnvironment effect.

[ojeda]

A safe attribute could trivially be added to checked handle-based APIs

If projects/APIs start to get annotated with a safe attribute ("no UB"), it would help getting standard attribute(s) for something like this in e.g. C (see the [[safe]] proposal: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2659.htm)