Effect System + Crate Permissions?

[Phosphorus-M]

This issue is a duplicate; the original was posted on Internal Rust. However, I’m interested in discussing it, it’s just an idea.

I want to see if people think this could be possible, even if it’s implemented using macros, similar to how contracts are handled, or perhaps through comments or some other mechanism.

---

Hello, how are you? I know I sometimes have rather unusual suggestions, and this one is no exception. I wanted to propose integrating a basic effects system, would something like this be feasible?

I noticed that in Koka, for example, functions often declare not only their return type but also the effects they produce. For instance, if a function prints something to the console, it must declare the effect "prints to the console". Similarly, if it reads or writes from the console, or performs file operations, these effects are explicitly declared. I realize implementing something similar in Rust would be challenging, perhaps achievable through macros, comments, or another mechanism. I’m not sure, but I wanted to suggest it because I believe it could evolve into a permission system for crates.

By analyzing the code, we could determine whether a crate requires access to the console, syscalls, files, or similar resources. This would allow us to track whether a crate, from one version to another, begins to access new capabilities it did not previously require, thus providing an additional layer of security, minimal, perhaps, but still valuable.

This could work similarly to Deno, which asks for permissions before execution (in our case, compilation), indicating for example: "this crate requires internet access", "this crate requires filesystem access" and so on.

I realize this is somewhat unusual, but I wanted to share the idea. It may seem trivial, but I truly believe it could help prevent supply chain issues within our ecosystem.

[SOF3]

These problems are better solved by a sandboxed environment like WASM. There are more ways to interact with a filesystem or internet in any OS than you probably imagined.

[bombless]

The problem is actually the ecosystem, i.e. crates.io.

The type system of Rust is already powerful enough to express Internet access or accessing console.

The first solution I can think of is to use linear type, you can check the Clean approach, which is fairly simple once you have linear type, which is already in the type system of Rust.
The second solution I can think of is like Haskell. Now Rust cannot really support HKT to the level of Haskell, but I think to label traits like "access to the console, syscalls, files, or similar resources", all you need is to label function call propagation for i.e. each function, to create a pseudo-experience of effect system.

After you have the infrastructure to do the labeling you mentioned (which as mentioned above is already doable), there's hard work to label every function that existed to reflect their effect. And you need to do it in a different ecosystem, that is, you need to make new set of std libraries, and an alternative to crates.io, because the libraries exist today already mess up with "access to the console, syscalls, files, or similar resources" without labels.

I think, just before Rust 1.0, the major architecture designer of Rust at that time, niko, made a post to describe why we need to discard type support for green thread (or think twice before we fully support async IO and sync IO, I don't know). The idea is that we already have families of types like &/&mut, Send/!Send, etc., each of these pairs add one dimension to type universe which add burden for beginner to learn and master Rust. The effect labeling system can make that burden to explode, because you can easily think of tens of different effect, and bear in mind that the linear growth of label will make the burden grow exponentially.