Accept Vec and slice arguments to encode_polyline #7
Conversation
This is both more flexible and potentially more efficient, since slices require a single pointer dereference, and Vecs require two.
| @@ -38,17 +38,20 @@ fn encode(current: f64, previous: f64, factor: i32) -> Result<String, String> { | |||
| Ok(output) | |||
| } | |||
|
|
|||
| /// Encodes a Google Encoded Polyline. | |||
| /// Encodes a Google Encoded Polyline. Accepts a Vec or slice | |||
There was a problem hiding this comment.
It actually just accepts a slice. Since a Vec can Deref to a slice, the Vec is treated as a slice. Anything that can Deref to a slice (or a slice itself) can be passed as an argument.
There was a problem hiding this comment.
How about "Accepts a slice or anything (such as a vec) that can deref to a slice"? I'm just thinking of making it explicit for people who aren't necessarily aware of the exact relationship between the two.
|
@tmcw This pull request looks good to me? Can I merge or do you want to do so? Tangentially, it looks like you're the only one with crates.io publish access for the library. If this is intentional, carry on. Otherwise, you can use |
|
👍 merging, feel free to merge @frewsxcv and just updated the crates to include the georust organization. |
This is both more flexible and potentially more efficient, since slices require a single pointer dereference, and Vecs require two.
It also has the (potential) benefit of simplifying FFI interaction, since it's easier and more efficient to create slices than Vecs from pointers to data allocated outside Rust.