Collecting downvotes since before forums even had thank you’s.

  • 6 Posts
  • 91 Comments
Joined 3 years ago
cake
Cake day: July 6th, 2023

help-circle


  • great article!

    Is it?

    I didn’t read past the first sentence:

    The Arc type is Rust’s thread-safe smart pointer

    This is horrible in my view. All types that implement Deref and/or DerefMut can be called smart pointers, and everything is “thread-safe” in safe Rust.

    If I had to call something “Rust’s thread-safe smart pointer”, it would be the actual references &T/&mut T where T: Send + Sync.


    Digression: All the traits involved like the 4 mentioned above point to the C++ centric concept of smart pointer not mapping cleanly to Rust semantics imho. But that’s a long lost battle.


    Let’s see what the official Arc docs say:

    A thread-safe reference-counting pointer.

    Will you look at that! An actually accurate short description that is already available.


    While not widespread, there is already a small myth out there that paints Rust as if it’s Swift-like, a ref-counting centric language.










  • I think the other user meant that ls output is not supposed to be treated as parsable, because the tool doesn’t offer any guarantees in that regards.

    Shells have built-in support for globbing files anyway. xargs is also not needed. If someone is allergic to using a shell for loop, find always had -exec with ; instead + which wouldn’t trip on too many arguments.



  • Using cells in your solution is smelly, when you can simply use two transparent wrappers with Ref or RefMut access, so you have actual compile-time checking instead of janky checking at runtime (which is also not zero-cost).

    The allow/deny variants could themselves hold & or &mut references too if we are going with that route. But it all depends on the precise problem OP is having and what is the best workable solution for it looks like.