Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get function takes a pointer to usize? #10

Closed
Binero opened this issue Nov 10, 2015 · 15 comments
Closed

get function takes a pointer to usize? #10

Binero opened this issue Nov 10, 2015 · 15 comments

Comments

@Binero
Copy link
Contributor

Binero commented Nov 10, 2015

Why does the get function (amongst others) take a pointer to usize, as opposed to just a usize?

https://github.com/contain-rs/vec-map/blob/master/src/lib.rs#L433
https://github.com/contain-rs/vec-map/blob/master/src/lib.rs#L457
https://github.com/contain-rs/vec-map/blob/master/src/lib.rs#L475
https://github.com/contain-rs/vec-map/blob/master/src/lib.rs#L475

@apasel422
Copy link
Contributor

The reason is essentially consistency with the other map types (e.g. BTreeMap).

CC contain-rs/bit-set#5.

@Binero
Copy link
Contributor Author

Binero commented Nov 11, 2015

Seems like a waste of resources to me.

@apasel422
Copy link
Contributor

With inlining and other optimizations, I'd say the main downside to the current situation is syntactic noise. I'd be in favor of merging a pull request that changes these to take the usize by value.

@Binero
Copy link
Contributor Author

Binero commented Nov 11, 2015

Such a change would be a breaking change. If I were to write a PR, would it be approved?

@apasel422
Copy link
Contributor

Other people from @contain-rs/owners can chime in on whether such a minor change is worth breaking backwards compatibility, but if we do merge such a PR, we can bump the crate's version to indicate that there was a breaking change.

@Binero
Copy link
Contributor Author

Binero commented Nov 11, 2015

cc @reem

@Gankra
Copy link
Contributor

Gankra commented Nov 11, 2015

We have 12 reverse dependencies https://crates.io/crates/vec_map/reverse_dependencies and all of them are presumably going to break if we make this change. That seems way too brutal for something that I'd be surprised to not see inlined away.

CC @HeroesGrave @simnalamburt @andelf @johanneskoester

@johanneskoester
Copy link

In my opinion, it would be better to get the API right at this early stage of rust instead of breaking later when hundreds of packages depend on this.

@Binero
Copy link
Contributor Author

Binero commented Nov 11, 2015

I would have to agree with this.

@HeroesGrave
Copy link

I'm fine with it being changed. In all the cases where I used it I was calling vec_map.get[_mut](&index) anyway.

Assuming all of the downstream crates aren't using wildcard dependencies, it really shouldn't be that much of an issue anyway.

@Binero
Copy link
Contributor Author

Binero commented Nov 11, 2015

Well looking at what happened when libc updated recently, I wouldn't make that assumption.

@Gankra
Copy link
Contributor

Gankra commented Nov 16, 2015

Upon reflection, if a trait is ever added, it can trivially dispatch to the proposed interface. So 👍 let's ship it.

@Binero
Copy link
Contributor Author

Binero commented Nov 18, 2015

Do we have a consensus here that the get function should take a value?

@apasel422
Copy link
Contributor

@Binero I think so. You can submit a PR if you'd like.

@apasel422
Copy link
Contributor

This was closed in #11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants