3 ms·
Almost half of the article is dedicated to fighting Rust. Rust compiler doesn't permit this, doesn't permit that... May the authors of Rust excuse me, but that
by LessDmesg 7y ago
Almost half of the article is dedicated to fighting Rust. Rust compiler doesn't permit this, doesn't permit that... May the authors of Rust excuse me, but that language is as much not fun to program in as it is thought-out and well-designed!
- phil-opp 7y agoOn 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).
- LessDmesg 7y agoBoth 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 7y agoFor 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 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.
- justincredible 7y agoNothing's more fun than shooting yourself in the foot.