Allow for string names when instantiating or updating records

[yrashk]

This provides a great added benefit of allowing to import untrusted
dictionary-like structures without having to sanitize keys before
converting them to atoms, without the risk of running out of atoms.

The performance for atom field names remains the same, string names
are somewhat slower (as expected)

[josevalim]

I assume "attribute_name" wouldn't be a valid type?

[yrashk]

I am just cutting out what is used in options_spec. I think that's right.

[josevalim]

Yeah, I know. The thing is that options_spec has something like this: [{ :bar, integer } | { :baz, string }], so we have types per option. I am wondering if we can't have the same here, but the strings as keys.

[josevalim]

Thanks! It would probably be better to have two distinct clauses though, one for atoms and another for binaries, instead of having mixed keys as this makes the atoms implementation twice slower for the cases there is a miss.

[yrashk]

My timing showed that there is no difference in timing for atoms at all. Same timing, and only slower for binaries (which is expectable)

[josevalim]

@yrashk Let's suppose you have a record with 10 fields. And you call Record.new(foo: "123"). Previously, we checked for the other 9 fields if the atom key existed. Now, we are checking if either the atom or binary key exists, which is extra cost.

Also, I don't think allowing mixed keys would be a good idea. Even the added @spec says you should either have a list of atom keys or a list of string keys.

[yrashk]

@josevalim I've updated this PR as per discussion we had

[devinus]

Can we make this any Dict.t?