4 ms·

The presence of this list is very helpful. Unfortunately, some of the points are controversial. > Types eagerly implement common traits This is particularly c

• volta83 5y ago
  > If my 4K structure can be copied, should it derive `Copy`? This leads to users implicitly copying it around instead of using references more aggressively. Rust eliminates unnecessary memcpys, but this is a bit up to you. `Copy` as a synonym of "cheap to copy" is used by some crates, although this is not official AFAIK. > If all my types implement `PartialEq`, `Debug`, and other stuff, that means a lot of code generation at compile time, If you don't use these, no LLVM-IR is even generated for these. Rust compiles code "on demand".
  • kvark 5y ago
    Then you are at mercy of Rust optimizer. I don't want to always think about Rust optimizer when looking at or reviewing the code. I want to see the costs explicitly in the code. Once Copy/Debug/PartialEq are derived, it will be tempting to use them, so the compile time cost will apply.
    • tialaramex 5y ago
      This is an API guide. So what you're talking about is deliberately making libraries you provide worse so that people aren't tempted to use them, that ought to be ringing some alarm bells.
    • volta83 5y ago
      These are guidelines that the standard library aims to follow. It does not blindly follow them, and they only represent the values and trade-offs that make sense for the standard library. If your projects have different values and trade-offs, just do your own thing (Rust's makes it easier than all other languages I know). If you don't want to use a standard library that follows these, just fork it and change it. Rust makes this trivial, and projects that must do this go and just do it. I really don't know what point you are trying to make. Implementing Copy for all types that are cheap to copy makes sense for most Rust programmers. That does not mean that it makes sense for _you_, but if you disagree about this not making sense for most, then Rust is probably the wrong language for you, and you should consider using something else.
• tialaramex 5y ago
  If you really believe your users won't understand this is a ~4K object and might foolishly copy it when they didn't mean to, implement Clone instead so that they can have another one if that's what they really meant. If you're exaggerating and the object is really 64 bytes, just suck it up and derive Copy, your estimate of how "expensive" it is may well be so wrong that you're defeating your own objectives. I've never seen any indication that unneeded PartialEq or Debug for example aren't elided by the compiler. In contrast if I need Debug it sure is a pain in the backside to implement it manually in a wrapper type because the owner of the type decided unilaterally that nobody would need that.
  • kvark 5y ago
    I want to see the costs in the code, not imply them. Also, profiling programs in Rust often shows full of memcopies. Saying that they are nicely optimized out is dishonest.
• deleted 5y ago
  [deleted]
• hcs 5y ago
  There is a clippy lint, pedantic and allowed by default, that warns about passing a large type by value. https://rust-lang.github.io/rust-clippy/master/#large_types_passed_by_value https://rust-lang.github.io/rust-clippy/master/#large_types_... The default threshold is 256 bytes: https://github.com/rust-lang/rust-clippy/blob/1fc1aee7be6e7e71f12eacd60b9b1040e7640fe4/clippy_lints/src/utils/conf.rs#L213 https://github.com/rust-lang/rust-clippy/blob/1fc1aee7be6e7e... So you might use that as a rule of thumb. But officially, "Generally speaking, if your type can implement Copy, it should." https://doc.rust-lang.org/std/marker/trait.Copy.html#when-should-my-type-be-copy https://doc.rust-lang.org/std/marker/trait.Copy.html#when-sh...
  • kvark 5y ago
    That's going to be helpful to enable in WebRender/Euclid, thank you!