I would have been interested if the author had expanded on how they planned to use the borrow checker to avoid multiple listeners using the same IP address. I haven’t used rust much outside of some self learning but in other language I’d simply mutex/lock, how can the borrow checker at compile time validate that each listener cannot get the same value of a hash set?
- use `&mut` references to allow the borrow checker to statically enforce only one reference to the IP exists at a time (the major unique feature of Rust is the borrow checker which basically only allows one mutable reference at a time
- use an `UncloneableIp` new type that doesn't implement `Clone` to prevent the IP from being copied
I might be dense, but I still don’t get how it works: I put the 10 addresses in a HashSet, and I have some function that I want to be able to exclusively use one of them, how do I write the constraints to make the borrow checker be able to enforce this at compile time?
I understand the two statements above in the article, just not how they can be made to work in this case. Apologies again if this is an obvious question, as I was saying I am definitely just starting out in rust.
Hopefully that gets the gist of how you might approach it. I'm not sure I'd use the HashSet myself, to be completely honest, because it makes it needlessly complicated to get an element out of it. I'd probably just use a Vec.
Thanks for writing some code! I will try to spend some time to grok it: so is the idea basically that you are guaranteed there is only ever one copy of these unique IPs and there is absolutely no way for any more than one function to hold one? I have to say maybe HashSet was throwing me for a loop and if the important bit is having an object that can not be copied, then it shouldn’t matter what data structure you keep them in does it…
I don’t find a strong case for using Rust just to guarantee each thread gets its own IP (a mutex protected getter seems like it would do just fine for just that) but I guess it would guarantee that as long as you use this “uncopiable” object you could not, even if you wanted to, have two identical IPs in your program if I understand things correctly, which if your mutex getter had a bug would not protect you against.
The Mutex/RwLock would be a runtime guarantee, while with this, you can make it a compile-time guarantee.
I think that mutex are actually a really good example of what he's talking about in the article. You can only access the data from a Rust mutex through a `MutexGuard` returned from the lock method. `MutexGuard` is uncloneable and therefore, when it is dropped at the end of its scope, the mutex knows that it is free and can automatically unlock it. Additionally, it is impossible to access the data without having the `MutexGuard`, so you can statically determine at compile time that all data access is behind a lock.
The HashSet would be the owner of the IP address type. Your function would call the "take" method of the HashSet to take ownership of the IP address. Now the IP address cannot go back into the HashSet unless you give ownership back and no other thread/caller can take ownership.
