top | item 22233437

(no title)

phil-opp | 6 years ago

On the other hand, these strict requirements make sure that the global allocator is thread-safe. Also, I only count two compiler errors mentioned in this post and both have a valid reason (you can't modify values behind an immutable reference; you can't implement traits for types of other crates).

discuss

order

LessDmesg|6 years ago

Both of them are invalid. What if you want a single-threaded allocator without the mutex overhead? And forbidding implementing traits for some types is just arbitrary stupidity. Developers don't need a nanny compiler to tell them which types they can or can't extend. Orphan instances are the solution in some cases.

phil-opp|6 years ago

For single threaded programs you can e.g. use a Mutex implementation that only disables interrupts for the critical section (https://docs.rust-embedded.org/book/concurrency/#mutexes). Rust does not forbid you from doing these potentially memory unsafe things, it just requires you to use an `unsafe` block for this.

The reason for forbidding these trait implementations is compatibility. For example, the dependency might add an implementation for the trait at some point, so that there would suddenly be conflicting implementations after a semver-compatible update. You can still implement the trait by creating a wrapper type.