4 ms·

I wonder what the author would have preferred to the visual litter of `unsafe` blocks? Can you use `unsafe` to mark off entire scopes to avoid having to redecla

I wonder what the author would have preferred to the visual litter of `unsafe` blocks? Can you use `unsafe` to mark off entire scopes to avoid having to redeclare it? Seems unavoidable in a project that is meant to heavily interoperate with a C99 code base like Ruby. Cargo having to phone home all the time sounds annoying, though. I hope that gets improved, though I know the cargo team is swamped right now.

steveklabnik 4y ago
> Can you use `unsafe` to mark off entire scopes to avoid having to redeclare it? Yes. > Cargo having to phone home all the time sounds annoying, though. It does not have to phone home, ever. They for some reason didn't seem to want to use the right workflow, but that workflow does exist, and is an important and well-supported use-case. (It seems from the bug report that they did hit a confusing error message, which is unfortunate.)
- faitswulff 4y ago
  Thanks for the clarifications!
  - steveklabnik 4y ago
    No problem. And I am serious about the "for some reason" bit, I don't know why `cargo vendor` isn't acceptable for them, but they know their requirements better than I do.
- tptacek 4y ago
  She gave the reason in the piece, and linked to the ticket she filed: https://github.com/rust-lang/cargo/issues/10352 https://github.com/rust-lang/cargo/issues/10352
  - steveklabnik 4y ago
    I read the piece and the ticket. I still don’t understand. That’s fine, it’s not my responsibility to anymore. I’m glad they found a solution they’re happy with. Specifically, cargo vendor was suggested in the ticket, but there was no response as to why it wasn’t adequate for this case, just that it doesn’t “feel” good. I’m probably missing something.
    - tptacek 4y ago
      The reason is right there in the ticket. They have exactly one dependency, and it's optional. They don't want to vendor it just so they can build the no-capstone artifact in CI without having to phone home to crates.io or whatever. You don't have to agree with her, but you can't pretend she didn't give a clear reason.
      - steveklabnik 4y ago
        Saying “we don’t want to” is technically a reason, sure, but it doesn’t mean I understand the why. Why is that a problem? (Depending on that why, I have an idea or two for a workaround, but you can’t suggest solutions until you understand the actual issue. I have my own laundry list of issues with Cargo that I have to work around; it’s painful and I have a lot of empathy for that.)
        tptacek 4y ago
        For all the same reasons that vendoring isn't the default option in any dependency management system in any language: because there is a cost to vendoring. She didn't say that, but I wouldn't think she'd have to. You don't vendor all of your dependencies either: why not? There's your answer. I'm wondering if maybe you've missed the part where they don't need this single dependency in the builds they're talking about doing. It seems like the Rust community people responding on the ticket had no trouble understanding what the issue is. There's a difference between acknowledging something and conceding that it needs to be changed.
        steveklabnik 4y ago
tptacek 4y ago
For what it's worth: the complaint here makes sense, but "unsafe" isn't just telling the compiler what's going on, it's (probably more importantly) telling other programmers what's going on.
tialaramex 4y ago
> Can you use `unsafe` to mark off entire scopes to avoid having to redeclare it? Yes, but, you should avoid labelling large blocks of code "unsafe" when really only a small amount is unsafe or there are disconnected unsafe bits scattered through a function. Also, though the compiler can't tell, stylistically it's proper in Rust to justify each unsafe block, and larger blocks mean the justification is often too vague ("Access the data" thanks, but why is this OK?) or falls out of date. The idea is: Unsafe does not mean "I expect this is wrong but I want to do it anyway" rather "I am sure this is right but the compiler doesn't understand why" and the justification explains to other humans, maintainers, reviewers, and your future self, why you believe it's right.
- pdimitar 4y ago
  > The idea is: Unsafe does not mean "I expect this is wrong but I want to do it anyway" rather "I am sure this is right but the compiler doesn't understand why" and the justification explains to other humans, maintainers, reviewers, and your future self, why you believe it's right. I'd add one more aspect to it in addition to yours: "get back to this in the future and see if we can make it not use `unstable`". It's a very good marker in the code and I hope Rust doesn't move to implicitness.
  - tialaramex 4y ago
    Did you mean "unsafe" there ? Unstable aka Nightly features in Rust also need flagging, you must annotate to tell the compiler you want this feature (and so your code won't compile in stable Rust or in any future nightly Rust which lacks the feature) No I don't think Rust would choose to make either nightly flags or the unsafe marker implicit. In fact the opposite is likely, today unsafe functions have their body implicitly treated as unsafe, because you said the unsafe word at the start of the function. For short functions this seems convenient, in longer functions it would be nice to distinguish "actually needs its own safety rationale" from merely "happens to be in a function marked as unsafe".

steveklabnik 4y ago

> Can you use `unsafe` to mark off entire scopes to avoid having to redeclare it? Yes. > Cargo having to phone home all the time sounds annoying, though. It does not have to phone home, ever. They for some reason didn't seem to want to use the right workflow, but that workflow does exist, and is an important and well-supported use-case. (It seems from the bug report that they did hit a confusing error message, which is unfortunate.)

faitswulff 4y ago
Thanks for the clarifications!
- steveklabnik 4y ago
  No problem. And I am serious about the "for some reason" bit, I don't know why `cargo vendor` isn't acceptable for them, but they know their requirements better than I do.
tptacek 4y ago
She gave the reason in the piece, and linked to the ticket she filed: https://github.com/rust-lang/cargo/issues/10352 https://github.com/rust-lang/cargo/issues/10352
- steveklabnik 4y ago
  I read the piece and the ticket. I still don’t understand. That’s fine, it’s not my responsibility to anymore. I’m glad they found a solution they’re happy with. Specifically, cargo vendor was suggested in the ticket, but there was no response as to why it wasn’t adequate for this case, just that it doesn’t “feel” good. I’m probably missing something.
  - tptacek 4y ago
    The reason is right there in the ticket. They have exactly one dependency, and it's optional. They don't want to vendor it just so they can build the no-capstone artifact in CI without having to phone home to crates.io or whatever. You don't have to agree with her, but you can't pretend she didn't give a clear reason.
    - steveklabnik 4y ago
      Saying “we don’t want to” is technically a reason, sure, but it doesn’t mean I understand the why. Why is that a problem? (Depending on that why, I have an idea or two for a workaround, but you can’t suggest solutions until you understand the actual issue. I have my own laundry list of issues with Cargo that I have to work around; it’s painful and I have a lot of empathy for that.)
      - tptacek 4y ago
        For all the same reasons that vendoring isn't the default option in any dependency management system in any language: because there is a cost to vendoring. She didn't say that, but I wouldn't think she'd have to. You don't vendor all of your dependencies either: why not? There's your answer. I'm wondering if maybe you've missed the part where they don't need this single dependency in the builds they're talking about doing. It seems like the Rust community people responding on the ticket had no trouble understanding what the issue is. There's a difference between acknowledging something and conceding that it needs to be changed.
        steveklabnik 4y ago

tptacek 4y ago

For what it's worth: the complaint here makes sense, but "unsafe" isn't just telling the compiler what's going on, it's (probably more importantly) telling other programmers what's going on.

tialaramex 4y ago

> Can you use `unsafe` to mark off entire scopes to avoid having to redeclare it? Yes, but, you should avoid labelling large blocks of code "unsafe" when really only a small amount is unsafe or there are disconnected unsafe bits scattered through a function. Also, though the compiler can't tell, stylistically it's proper in Rust to justify each unsafe block, and larger blocks mean the justification is often too vague ("Access the data" thanks, but why is this OK?) or falls out of date. The idea is: Unsafe does not mean "I expect this is wrong but I want to do it anyway" rather "I am sure this is right but the compiler doesn't understand why" and the justification explains to other humans, maintainers, reviewers, and your future self, why you believe it's right.

pdimitar 4y ago
> The idea is: Unsafe does not mean "I expect this is wrong but I want to do it anyway" rather "I am sure this is right but the compiler doesn't understand why" and the justification explains to other humans, maintainers, reviewers, and your future self, why you believe it's right. I'd add one more aspect to it in addition to yours: "get back to this in the future and see if we can make it not use `unstable`". It's a very good marker in the code and I hope Rust doesn't move to implicitness.
- tialaramex 4y ago
  Did you mean "unsafe" there ? Unstable aka Nightly features in Rust also need flagging, you must annotate to tell the compiler you want this feature (and so your code won't compile in stable Rust or in any future nightly Rust which lacks the feature) No I don't think Rust would choose to make either nightly flags or the unsafe marker implicit. In fact the opposite is likely, today unsafe functions have their body implicitly treated as unsafe, because you said the unsafe word at the start of the function. For short functions this seems convenient, in longer functions it would be nice to distinguish "actually needs its own safety rationale" from merely "happens to be in a function marked as unsafe".