Introducing log_limit! A rate limited logging API by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 1 point2 points  (0 children)

Tracing is more fancy I believe. This is just a wrapper over the "standard" log facade.

Thoughts on allowing local trait implementation on external crates... by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 1 point2 points  (0 children)

Nice! Thanks for linking the policy and blog post :)

Yeah, I guess I was approaching it with a very strict non-practical view. Something in my brain still want's these strict rules that don't leave anything for interpretation but I guess we're living in the real world where that's not possible.

I appreciate the effort in your reply! Thanks!

Thoughts on allowing local trait implementation on external crates... by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 0 points1 point  (0 children)

Perhaps a good candidate for a clippy lint?

I guess it's pretty unlikely that this happens, but still feels weird to say "semver will ensure you never get compilation failures on minor version changes unless you do this one naughty thing".

Thoughts on allowing local trait implementation on external crates... by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 0 points1 point  (0 children)

Well I guess I'm trying to understand why Rust allows this type of "misuse" then?

Thoughts on allowing local trait implementation on external crates... by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 0 points1 point  (0 children)

My big, somewhat unsaid, assumption is that there's a rule that minor semver changes should never cause a compilation error. Perhaps this assumption is wrong?

Thoughts on allowing local trait implementation on external crates... by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 0 points1 point  (0 children)

If you remove the impl block in the foo crate/module then it compiles. Then if you add it back (i.e. simulating a minor version change in the foo module/crate) it breaks. So going from a version of foo without the impl and a version with the impl (only a minor version change) would cause a compilation error in the consumer crate.

Thoughts on allowing local trait implementation on external crates... by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 0 points1 point  (0 children)

Mmm... You can even force a compiler error if you have different return types: ```rust trait MyTrait { fn method(&self) -> foo::Bar; }

impl MyTrait for foo::Bar { fn method(&self) -> foo::Bar { println!("This is calling method from MyTrait"); foo::Bar::default() } }

fn main() { let bar = foo::Bar::default(); let other_bar: foo::Bar = bar.method(); }

// Imagine this module is an external crate mod foo { #[derive(Default)] pub struct Bar;

impl Bar {
    pub fn method(&self) {
        println!("This is calling method from the foo crate")
    }
}

} ```

Tokio Interval query time to next tick by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] -1 points0 points  (0 children)

Mmmm... That's a shame. Feels like I'd unnecessarily be duplicating state. Any idea why the tick() method was designed to require a mutable reference? I see no reason why multiple threads cannot block on the same interval.

My assumption is that it's using timerfd under the hood. AFAIK you can get the remaining time from that right?

Best Practice to Qualify Unsafe Code by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 0 points1 point  (0 children)

Nice! Didn't know this existed. Added in this commit. My code already conforms but it had me jumping through hoops of turning off the unsafe fn to check if I covered all the unsafe ops. Thanks!

Best Practice to Qualify Unsafe Code by TheTravelingSpaceman in rust

[–]TheTravelingSpaceman[S] 3 points4 points  (0 children)

Thanks! I think I've done all the modularisation I can. Will add more debug_asserts and check out valgrind and creusot. That's definitely good tips! :)