Behavior for Duplicate Dictionary Entries?

[InsertCreativityHere]

Like many languages, Rust's main dictionary type is the HashMap.
An unordered map, with unique keys.

What should the behavior be for decoding a dictionary with duplicate keys?
For example, if this is received across the wire: [3][(5, "hi"), (12, "he"), (5, "ha")].

The language guide is very clear on this. One of the first points we state in the dictionary docs is that each key must be unique:
https://docs.icerpc.dev/slice2/language-guide/dictionary-types

And, in C#, we strictly enforce the spec, but I suspect we only do so by accident.
Dictionary.Add throws an exception if you attempt to add a key which already exists.

Should we also strictly enforce the spec in Rust too?
By returning a decoding error if we encounter a duplicate key.
Currently, we just call HashMap::insert, which will happily update an existing key with a new value upon seeing a duplicate.

Some nuance:
The receiver still upholds the rule. Our HashMap does still have unique keys. The real problem is with the sender.
The sender sent us a 'bad' dictionary. So, is it really worth explicitly checking each insertion for uniqueness when:

• this only happens in the rare case where I was sent garbage, which is on them.
• and whether or not we return an error, we will still be upholding all the requirements of the type?

[bernardnormier]

Yes, the recipient should have a "checked" behavior and reject invalid dictionaries. Not tolerate them in some manner.

The same is true for any other invalid value, like:

• an out of range checked enum
• a string with invalid bytes
• ...

Feel free to add a unit test if you are concerned we're not paying sufficient attention to this situation.

And, in C#, we strictly enforce the spec, but I suspect we only do so by accident.

It's not by accident. Why do you think it is?

We could catch the ArgumentException thrown by Add in the dictionary decoding extensions and wrap it in an InvalidDataException to make it clearer.

[InsertCreativityHere]

Okay, I'll fix the decoding to be strict. That's what I was leaning towards as well.

It's not by accident. Why do you think it is?

You pretty much nailed it.
I compared it to our String and Bool decoding (the two primitive types which can have invalid representations), and I saw we were explicitly throwing InvalidDataException. But I didn't see us doing the same for Dictionary decoding, nor did I see any comment about it how Add would throw in this case.

So, I think I'll also open a PR to catch and rethrow the ArgumentException like you suggest.
We're already doing that in the string decoding logic after all.