-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
'unsafe' keyword should expect Expression instead '{}' #3431
Comments
unsafe code blocks are intentionally scary so that you know about it. In fact my opinion is that AST-aware editors should syntax highlight the entire unsafe block to make it even more scary. If you have a problem with braces, I think more people would be interested in seeing if/else expressions without braces (especially the |
hi SOF3, i don't think unsafe blocks should be scary, i saw them like that when i was a beginner, also this automatically makes unsafe more painful to use, which would sound good, but if you use unsafe in first place you want at least clean code. |
why is everyone downvoting i can't understand what is wrong lol |
My point, as illustrated above, is that braces are not that ugly. Just like people writing C barely complain the verbosity of writing a |
you are right, in C there are many unnecesary parenteces. but i don't think it immediatly means the lil' refactor of unsafe is not worth it |
IIRC, there was an RFC proposing The "uglification" of unsafe code, which currently affects both unsafe and especially raw pointers is a wrong strategy, IMO, unsafe code should be more convenient to write, distracting syntactic noise doesn't bring any extra correctness, quite otherwise. |
i agree, uglification of unsafe doesn't brings correctness, clean code potentially does |
What is the idiomatic scope of let value = unsafe {
// `ptr` is a valid pointer due to xxx reason
&*ptr
}; or // `ptr` is a valid pointer due to xxx reason
let value = unsafe { &*ptr }; The braces are quite commonly used for encapsulating the comment with the actual unsafe block. There's no
@cubodix I agree with that indeed, in Go they have the exact same problem where the explicit error checking worsens readability of error processing logic. I am just concerned why the unsafe operation itself is not complex enough to be on its own line. |
Quite often the unsafe operation is just a call to a FFI function, for example. |
I actually don't see often What mostly happen is that there is multiples unsafes scattered over a function like this: fn init_drivers() {
// do some stuff
let mut driver = unsafe { get_device().driver };
peripheral_control = driver.peripheral;
// some other stuff
let peripherals = unsafe { peripheral_control.scan() };
// more code
} Ah! But that's ugly, so what often happen is that the two are merged fn init_drivers() {
// much cleaner
let peripherals = unsafe {
let mut driver = get_device().driver;
peripheral_control = driver.peripheral;
peripheral_control.scan()
}
// ...
} And I find this to be a bit of bad coding practice, yet I see it everywhere! I also think that the ugliness of unsafes make it enticing at times to mark an entire function as unsafe Some solutions?Maybe unsafes could be called with Or at worst, make every unsafe uniform in syntax: unsafe {
fn steal() -> Self {
// ...
}
} |
How are parentheses any better than curly braces? |
They prevent people from grouping multiple unsafe blocks together |
While I find the idea of making |
Oh yeah, that was bit far fetched. My point was more that, unsafe blocks are ugly and that minimises how much they are used in code, but that doesn't minimises the amount of unsafe code. |
Speaking of let arr = [const String::new(); 4];
let my_future = async println!("ping {}ms", ping([1, 1, 1, 1].into()).await); |
the most compelling motivation for me (i am in favour of forcing // old syntax:
let x = unsafe {
do_thing(*with_terribly_extremely_long_variable_name);
};
// new syntax:
let x = unsafe do_thing(
*with_terribly_extremely_long_variable_name,
); to me at least, its much more obvious in the first example that the dereference in the argument expression might be itself unsafe since it's written without ambiguity within the |
Would |
what do you want from the lonely little scope? what has it done to you? |
|
unsafe keyword is only valid this way:
unsafe { unsafe_function() }
but it cloud be more better if unsafe cloud be written this way:
unsafe unsafe_function()
unsafe {}
->unsafe *expression*
The text was updated successfully, but these errors were encountered: