Conversation
| r.map_field = {{"hello", "world"}, {"world", "bye"}}; | ||
| EXPECT_EQ(r.AccessMap(), r.map_field); | ||
| EXPECT_EQ(r.AccessMapEntry(), "world"); | ||
| EXPECT_EQ(r.AccessMapEntryWithComputedField(), "world"); |
There was a problem hiding this comment.
I am wondering if we should have a test that confirms that we throw if the key is not there. Right now we rely on https://en.cppreference.com/w/cpp/container/unordered_map/at to do that, so we are pretty sure that is the case, but if we later on switch the underlying implementation or we use this set of tests as a template later to write tests in another language, then we might miss it. Note that the [] operator of unordered_map creates the entry if it doesn't exist (https://en.cppreference.com/w/cpp/container/unordered_map/operator_at).
|
|
||
| func UnmarshalMapYAML(value *yaml.Node) (*GeneralizedType, error) { | ||
| if value.Kind != yaml.MappingNode { | ||
| return nil, parseError(value, "a !map must be specified with fields `keys` and optionally `values`") |
There was a problem hiding this comment.
I think both keys and values are mandatory fields. We did discuss keys defaulting to string, but it doesn't currently right? I think that is the way it should be.
There was a problem hiding this comment.
Ah yes, that error message is wrong. Will fix.
hansenms
left a comment
hansenms
left a comment
There was a problem hiding this comment.
This looks great. Really nice with the short-hand for these too.
2 participants
Adding a map/dictionary datatype.
The shorthand syntax is
And the full syntax (which allows more complicated value types):
They map to an
std::unordered_map<K, V>, support generic type parameters, and can also be used in computed expressions (size(myMap)ormyMap["myKey"]).Addresses #47