[alkonaut]

Sorry yeah I mean "resolve the dependency versions" from the listed version requirements, and if needed downloading them. "Restore" is used by e.g. NuGet (.NET) as you suggest and others (npm for js, etc).

The cargo dependency resolver runs and the results can be viewed by cargo tree. I saw in the docs now that cargo tree -d can be used to help find incompatible packages.

[tialaramex]

The idiomatic Rust way to avoid a scenario where we might have different versions of the unique IDs is to reify unique IDs as an actual type (say named UniqueID) rather than just having a tacit understanding that these particular integers are supposed to be unique.

This lets the type's owner decide what affordances to give it (probably adding two UniqueIDs together is nonsense, but comparing them for equality definitely makes sense - should they be Ordered... chronologically? Or not?)

But importantly here now that it's a type, Rust knows counter v 1.2.3 UniqueID and counter v 4.5.6 UniqueID are different types, even though they have the same spelling. So this code now won't compile unless everybody is consistent e.g. the Frogs and Wizards all use v 1.2.3 but the unrelated Space Combat module works with v 4.5.6 UniqueID. Code that looks like it could work, where we try to use the unique ID of a Wizard as the identify of a sub-space laser blaster won't compile.

[alkonaut]

That safety is merely accidental, it only appears if the dangerous state (the atomic counter memory location) is in the same crate as the UniqueNumber type exposed.

A pair of crates (one which defines the struct UniqueNumber(u32), and one which produces sequences of them) would still be suffering from this, because the sequencing crate could use v1 of the unique number struct crate, in both its v1 and v2.

This of course is even more contrived (now we have a specific split of state and types instead). So the real question is: does this happen in non-contrived scenarios in the wild?

[tialaramex]

I feel like the separate crate with UniqueNumber(u32) is a bad idea. There's nothing unique about these, you're gas lighting me. Like a PrimeNumber(u32) that's just a thin wrapper and expects somebody else to ensure they're prime - no, I know the compiler doesn't understand English, but these aren't prime (or unique) numbers, you're bad at your job.

One of my favourite decisions about Rust which could have gone the other way was their choice to define &str (and String) to be actual text. &str is basically &[u8] but with an extra requirement that this is valid UTF-8 text, likewise then String is basically Vec<u8> but requiring UTF-8.

I feel like UniqueNumber is the same, if you call yourself UniqueNumber don't just be a thin wrapper around an integer, you need to own that uniqueness problem.

[alkonaut]

A GUID is just a string or handful of bytes. It’s not reallt globally unique despite the name, unless we actually initialize it correctly…

But yeah I get your point.