Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is unsafe too loose a term? #50

Open
rrama opened this issue Oct 11, 2024 · 1 comment
Open

Is unsafe too loose a term? #50

rrama opened this issue Oct 11, 2024 · 1 comment

Comments

@rrama
Copy link

rrama commented Oct 11, 2024

The description says "The unsafe keyword is a clear signal of intent that a developer is choosing to work with shared memory multithreaded code." However, if I were to read code with an unsafe block without reading the proposal, I would not know that it is a signal that the "developer is choosing to work with shared memory multithreaded code." As to me the term "unsafe" does not inherently indicate this.
BUT, I will conceed that this is a very minor nitpick since I am aware that this is a feature that is likely to only be used by very deep diving technical libraries & frameworks and is something the average developer will never write or even see. Could it be made clearer what the code in the block is being allowed to do?

Secondly, are this is restricting future use of the term "unsafe", which may be a useful term elsewhere in the language? If someone wanted to expand what unsafe operations are allowed in an unsafe block in the future, could we end up with a scenario where too many safety checks are disabled when in an unsafe block and the code is allowed to be unsafe in more ways than the developer was intending?

The only suggestions I have are either using a different term entirely or specifying what unsafe operation(s) you are going to be performing as an option to the unsafe block, like so:

unsafe (shared_struct_access, some_future_unsafe_operation) {
  ctr.value = 1;
}

While I am personally not a fan of that as a solution (even with just 2 operations it's very bloated), I just wanted to let others have a think about it, as I could see it becoming the only viable bodged in solution should another unsafe operation be added in the future, so best to give it some thought now.

If someone does have a better solution, I'd love to hear them. As I really hope not to be mentioned in a future propsal where this syntax is being considered for real.

I hope I've made it apparent how this whole issue is quite minor, nitpicky, irellevant, etc., so no need to spell it out in a comment, please just react with a 👎 if you have considered the hypertherical problems mentioned but don't think anything needs to change.

@uncaught
Copy link

I would argue that unsafe is actually the wrong term entirely because it is judgemental. I wouldn't want to have unsafe everywhere, just because I'm developing multi-threaded. It gives me vibes of doing something forbidden or dirty.

I know rust uses the unsafe, too, but there it disables actual memory safety features. And you can use shared objects without going unsafe.

How about sharing? A sharing block allows access to shared objects. Wouldn't that be nice and clear?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants