entry API v3

[Gankra]

Replace Entry::get with Entry::default and Entry::default_with for better ergonomics and clearer code.

*map.entry(key).default(0) += 1;

// vec![] doesn't even allocate, and is only 3 ptrs big.
map.entry(key).default(vec![]).push(val);

let val = map.entry(key).default_with(|| expensive(big, data));

Rendered

[Stebalien]

How about or_insert/or_insert_with? Personally, I associate default() with Default::default() and, regardless, I don't expect a default() method to modify anything. Additionally, this allows default to be used to insert the Default::default() value:

map.entry(key).or_insert(0) += 1
let val = map.entry(key).or_insert_with(|| expensive(big, data));
map_of_vecs.entry(key).or_insert_default().push(0);

Drawback: or_insert... is long and ugly.

[reem]

It seems to me that we could get many of these benefits by replacing Result::unwrap_or_default with Result::default.

[huonw]

@reem that does something different (just returns the default value, ignoring the error, not inserting the default value into the data structure).

[huonw]

• Pass more information into the default_with closure.

[Gankra]

There's literally no information to pass for a vacantentry.

[huonw]

A reference to the key?

[Ryman]

@gankro Was this addressed somewhere off-thread or there's a technical reason it can't be done?

It would be neat to save a clone if the 'expensive' case requires the key to generate the value data.

[Gankra]

This API as a thin layer over Entry can't admit an &Key for the simple reason that Entry doesn't expose this. Otherwise it wasn't included in Entry simply because no one presented a compelling usecase (iirc every use of the old API I saw never used the key even though it was given). It's possible to add new methods that expose this functionality at a later date, though.

[reem]

@huonw You're right.

+1 to this RFC then, I think this is quite clean.

[Florob]

I concur with @Stebalien, I find the default() name confusing.
Semantically this feels like unwrap_or_insert(x), or get_or_insert(x). Obviously that is unwieldy to write, but I personally prefer its explicitness.
Generally I'm +1 one though.

[andrew-d]

Just as an interesting note, Python has something similar called setdefault.

[emberian]

you accidentally the tail end of this attr

[emberian]

This is nice, and hits all my uses of Entry.

[llogiq]

In the Java world, there are some libraries aiming to enhance collections usage, which have wildly different APIs, e.g. trove has adjustOrPutValue, while koloboke and Java 8 have compute, computeIfPresent, computeIfAbsent and getOrDefault.

Python has a dict.get(key, defaultValue=None), which we cannot reproduce because without varargs, and which does not allow us to lazily compute the value (which, given that python is not in the 'optimiize the heck out of it' camp, is simply not a problem they choose to solve).

In this context, the suggested API feels right. It's certainly more orthogonal than any of the API designs of other languages.

👍

[dhardy]

Really like the RFC.

Bike-shedding names: here's another suggestion (not necessarily better):

• entry(key).with_default(vec![]).push(val);
• let val = entry(key).with_default_fn(|| expensive(big, data));

[nikomatsakis]

I like the idea but I am not wild about the name. Certainly before reading the RFC I had no idea what default should do, and did not expect it to insert into the table. or_insert seems pretty decent to me.

[arthurprs]

That would be a great addition, as others already voiced I'm unsure about the naming.

[aturon]

Well done, @gankro!

I agree with what many have said about the naming (especially overlap with the Default trait). What about defaulted? I could live with or_insert, as well.

[Gankra]

👍 for or_insert as livable.

[cristicbz]

👍 can't get clearer than or_insert (and it's not that long either)

[brendanzab]

(&mut self, default: V) ?

[Gankra]

self for sure. Want to consume the entry.

[bluss]

Very nice API, I'd prefer the name .set_default(x). Prefer verbs. or_insert doesn't parse into anything sensible to me.. The reading "entry for key or insert x" is inevitable when you see .entry(key).or_insert(x) -- but we have already defined an entry to be either an occupied or a vacant entry, both valid.

[cristicbz]

or_insert() is a verb! and I think .entry(key).or_insert(...)
sounds like "get something or insert a value if it's not there".
set_default(x) doesn't make me think it returns the value was
previously there or a default. I could live with with_default as
well. But, yay bikeshedding!

On Tue, 3 Mar 2015 at 10:35 bluss notifications@github.com wrote:

Very nice API, I'd prefer the name .set_default(x). Prefer verbs.
or_insert doesn't parse into anything sensible to me..

—
Reply to this email directly or view it on GitHub
#921 (comment).

[aturon]

This RFC has been merged with overwhelming consensus. The merge updates the text to the or_insert and or_insert_with variants that many on this thread found appealing.

Tracking issue