Add a version of Uuid::from_fields that can't fail

[luser]

Uuid::from_fields takes an &[u8] for d4, so it will return an error if d4 is not 8 bytes in length. Every time I've used this method I've had an 8 byte array to hand, so it seems silly to have to call unwrap on the result. It would be nice if there was a version of this like fn from_fields(d1: u32, d2: u16, d3: u16, d4: &[u8; 8]) -> Uuid.

I realize that working with arrays is sort of a pain in Rust for several reasons. Once the const generics RFC gets implemented it should make some things simpler, like making it possible to have a method on slices that returns an array reference of a certain size.

[Dylan-DPC-zz]

Hi Ted,

Thanks. We will look into this. Instead of having seperate functions, I would prefer if we could use generics for this, if possible.

The earliest we can get this implemented & released is either 0.6.1 or 0.7.0.

Also you are free to send us a PR implementing this.

[luser]

I'm not sure what precisely you'd want to do with generics here, can you clarify?

[Dylan-DPC-zz]

I was thinking if we could have just one function that returns the UUID irrespective of data. But I think that won't be possible. Will add the function as you proposed.

[KodrAus]

It's not quite the same as the proposed from_fields method (since it takes the complete 16 byte array) but #145 offers an infallible way to get a Uuid from its raw representation.

[luser]

Oh, that is indeed very similar. In the uses I've found I can't just pass [u8; 16] because I'm reading the data from a file and it might need to be byte-swapped, unfortunately.

[kinggoesgaming]

I'm reading the data from a file and it might need to be byte-swapped, unfortunately.

I think that's a niche case, that should technically be handled by the library user before passing it to the library.

[luser]

I think that's a niche case, that should technically be handled by the library user before passing it to the library.

I am doing so, I just then don't have a method on Uuid I can call without needing to call unwrap on the result.

[kinggoesgaming]

@luser Can I see an example of how you are using this? Perhaps it might help get a better understanding on this

[luser]

Sure. This code hasn't actually landed anywhere yet, but it's a proposed patch to goblin:
https://github.com/luser/goblin/blob/b541e9584322c7e9c8e04b89db6d9be14d77e5c0/src/pe/debug.rs#L106

[Dylan-DPC-zz]

Looking again at this, i feel that having a similar method with the only change being a different return type doesn't make much sense to me. It will add more cost ot the maintainence later and there isn't much gain including it. We could provide a function to unwrap but then it will be the same as calling unwrap from outside and there is no visible gain in it.

[luser]

You are probably right. I think in the future when we have const generics and it's possible to easily get a reference to an array of a specific size from a slice designing APIs that use exactly-sized array references will be more ergonomic.

[KodrAus]

I’ve ended up circling back around to this while making a lot more things const. Fallible methods are still tricky for const.

The approach I was thinking of was to make from_fields take a &[u8; 8] and add a fallible from_fields_slice that takes a &[u8] for convenience. You can also still use try_into to convert a &[u8] into a &[u8; 8] now.

That would make Uuid::from_fields much more useful in const contexts.