Rfcs: Fix Borrow

[SoniEx2]

std::borrow::Borrow has an extremely limited API, making the following painful:

struct Thing (u8, String);
let m: HashMap<Thing, String> = Default::default();
// how to access m with u8, &str, avoiding allocations?

I recommend changing Borrow into Borrow<'a, T> so you can do Borrow<'a, &'a str> for String and derive it for multifield structs and stuff, reducing allocations all over the place.

[steveklabnik]

Wouldn’t this turn Borrow into Cow?

On May 7, 2018, at 10:05 AM, Soni L. [e-mail] wrote:

std::borrow::Borrow has an extremely limited API, making the following painful:

struct Thing (u8, String);
let m: HashMap = Default::default();
// how to access m with u8, &str, avoiding allocations?
I recommend changing Borrow into Borrow<'a, T> so you can do Borrow<'a, &'a str> for String and stuff.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[SoniEx2]

No? It just lets you have (u8, String) borrowing into (&u8, &str), so that both can be used to index a HashMap. It would also support Cow<(&u8, &str)> if you wanted it to.

[SoniEx2]

Alternative: Key trait, with impl Key for T where T: Borrow.

[burdges]

See the long thread on improving the Entry API via a new Query type.

[SoniEx2]

Key would be like, Key<'a, T>.

HashMap would take where K: Key<Q>, just like Borrow but different

(also, link?)

[SimonSapin]

The Borrow trait is #[stable], so making breaking changes to it such as adding a lifetime parameter is not acceptable.

I agree that HashMap with keys that contain String is missing some way to do a lookup based on &str, but fixing that requires at least a formal RFC with much more details and discussion of alternatives and trade-offs (probably after some exploratory discussion on internals.rlo), not just filing a two-sentences issue.

[SoniEx2]

surely we can change this in rust 2.0?

the Key<'a, T> solution would work, and be backwards-compatible. (anything currently assuming it takes a Borrow would still work because Key would be automatically provided for Borrow impls)

[Centril]

surely we can change this in rust 2.0?

There will never be a Rust 2.0 afaik.

[SimonSapin]

the Key<'a, T> solution would work, and be backwards-compatible

Then consider writing a much more detailed proposal for what that solution is

[burdges]

Afaik, all existing work towards doing this correctly lives in https://github.com/rust-lang/rfcs/pull/1769 and https://internals.rust-lang.org/t/pre-rfc-abandonning-morals-in-the-name-of-performance-the-raw-entry-api/7043 so this can probably be closed in favor of continuing those discussions somewhere like internals.

[SoniEx2]

hmm nope, that isn't what I have/had in mind at all.

[MajorBreakfast]

The best way to discuss a proposal without writing a full RFC is by opening a pre-RFC thread in the internals forum (https://internals.rust-lang.org/). Just try it: You'll quickly notice that most Rust users who respond to github issues also read and post in the internals forum.

Lately, various users have expressed their concern that new features that are added to the language should be vetted more throughly [[1](https://internals.rust-lang.org/t/idea-mandate-n-independent-uses-before-stabilizing-a-feature/7522)] [[2](https://internals.rust-lang.org/t/raising-the-bar-for-introducing-new-syntax/7458)]. This makes it even more important to follow the proper procedure for changes to the languages. Making a change without a proper RFC is impossible. But, as already mentioned, you can always create a pre-RFC in the internals forum, work out the details and then write the full RFC that follows the RFC template.

[Centril]

Since this doesn't seem to be going anywhere, I'm closing this. See @MajorBreakfast's comment if you want to move forward with this.