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.
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.