search

orlp / slotmap

Slotmap data structure for Rust
zlib License
1.16k stars 70 forks source link

Expose KeyData::new #31

Closed AndreaCatania closed 5 years ago

AndreaCatania commented 5 years ago

I need to create an opaque key.

I know that exist the proper function to do it, but I can't rely on that functionality since my opaque key is different.

For all the cases where the opaque key is not exactly like the one provided by this crate, would be nice have the possibility to use the function new to https://github.com/orlp/slotmap/blob/master/src/lib.rs#L244

It's unsafe crate IDs out of this crate, so an alternative to expose the new function is to create an unsafe function. Something like: unsafe create(id: u32, version: u32);

orlp commented 5 years ago

Could you clarify your use case a bit more and explain why Key::as_ffi and Key::from_ffi does not work for you? I don't know what you mean with "my opaque key is different".

AndreaCatania commented 5 years ago

I've an interface crate which provide an opaque ID that is composed by an index and its version. (Similarly to the KeyData). And I can't change this interface.

The implementor crate (which I'm developing) is using a Slotmap so I need a way to convert KeyData to the InterfaceID provided.

orlp commented 5 years ago

I've an interface crate which provide an opaque ID that is composed by an index and its version. (Similarly to the KeyData). And I can't change this interface.

Then you don't provide an opaque ID. If you provided an opaque ID you could change the underlying type. That's the point of an opaque ID.

I explicitly don't support splitting a key into an index or a version for my crate because it's an implementation detail I don't want to leak. Perhaps in future versions I would use less version bits and more index bits or vice versa. So I'm not going to provide Key::new, sorry.

Your best bet is to split the u64 returned by the FFI API into two 32-bit numbers and store those in your 'opaque' interface type. But this needs to come with giant warnings that I do not guarantee those two numbers are a version and an index (even if that is the case today) - they're just bits.

If this information gets edited in any way (e.g. the end user changes the version) then the results are unspecified. The only supported mode of operation is if the bits from as_ffi are the same as the ones given to from_ffi. How you store those bits in between those two calls is irrelevant.

AndreaCatania commented 5 years ago

My idea is to just have a way to reconstruct a Key, [using From and Into] from another struct. Not sure why this would be a problem for you, even if in future you plan to change something, and I think it's limiting the purpose of having a generic key type.

Probably I miss explained my use case. However, I respect this decision, thank you for the help!