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

luser commented

2018-02-15 08:07:47 -06:00

(Migrated from github.com)

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.

[`Uuid::from_fields`](https://docs.rs/uuid/0.6.0-beta/uuid/struct.Uuid.html#method.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](http://rust-lang.github.io/rfcs/2000-const-generics.html) 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 commented

2018-02-15 08:22:30 -06:00

(Migrated from github.com)

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.

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 commented

2018-02-15 09:55:02 -06:00

(Migrated from github.com)

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

Dylan-DPC-zz commented

2018-02-15 09:57:01 -06:00

(Migrated from github.com)

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 commented

2018-02-15 17:53:29 -06:00

(Migrated from github.com)

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.

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 commented

2018-02-15 20:19:13 -06:00

(Migrated from github.com)

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.

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 commented

2018-02-18 14:12:42 -06:00

(Migrated from github.com)

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.

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

2018-02-20 04:53:19 -06:00

(Migrated from github.com)

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.

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

2018-02-20 14:54:13 -06:00

(Migrated from github.com)

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

luser commented

2018-02-20 15:08:01 -06:00

(Migrated from github.com)

Sure. This code hasn't actually landed anywhere yet, but it's a proposed patch to goblin:
github.com/luser/goblin@b541e95843/src/pe/debug.rs (L106)

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 commented

2018-02-22 07:29:24 -06:00

(Migrated from github.com)

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 commented

2018-02-22 08:27:36 -06:00

(Migrated from github.com)

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 commented

2021-10-28 17:03:17 -05:00

(Migrated from github.com)

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.

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.

Rows
Columns

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

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