You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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?
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 anunsafe
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: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.
The text was updated successfully, but these errors were encountered: