would lead to an empty container being decoded instead of an error being thrown.
We now correctly throw a `DecodingError.typeMismatch` error in cases like this.
Fixes: #59
The current encoding APIs are generally non-throwing and so in a lot of places
we'd end up with a change to a throwing API if the various `encodeMap`
implementations were turned into throwing functions (some of them already are
though).
For now I've decided to leave this as are and use a `try!` in the cases where
the current `encodeMap` implementation is non-throwing. This will therefore lead
to runtime errors but I think this is fine for now given that the option to
forbid non-String map keys is opt-in.
It might be useful in the future to either change most/all of the
`encode`-relevant functions to be throwing. Either that or perhaps there could
be throwing versions to live alongside the non-throwing versions that currently
exist.
Also add support for another encoding and decoding option: `dateStrategy`. This
option accepts a value of type `DateStrategy`. The default value is
`taggedAsEpochTimestamp`, which is what the existing behaviour was. This means
`Date`s are encoded as tagged values, where the tag is `1` and the value is an
epoch timestamp.
The other value possible as a `dateStrategy` is `.annotatedMap`. This will
encode a `Date` as a map that looks like this:
```json
{
"__type": "date_epoch_timestamp",
"__value": 123456789
}
```
This is potentially useful for interacting with CBOR implementations that don't
support tagged values.
if they want map keys to be encoded as strings, where possible. This is relevant
for types such as those found in `Foundation` that conform to `Codable` and
whose coding keys can be encoded as either an `Int` or a `String`.
`Codable`.
Also now allows options to be specified that will control the encoding of the
keys in maps where they could be encoded as either an `Int` or ` String`. A new
option called `useStringKeys` is exposed which allows the user to request map
keys be encoded as `String`s
`Hashable`.
This allows us to check at runtime if an `Any` conforms to `CBOREncodable` and
therefore call its `encode()` implementation if it does.
Extra types have had `CBOREncodable` conformance added for them here as well.
Also update `Package.xcconfig` (and `SwiftCBOR.xcodeproj` as a result).
Parsing byte per byte leads to massively performance hit because Data objects are constantly recreated
# Conflicts:
# Sources/SwiftCBOR/Decoder/UnkeyedDecodingContainer.swift
Hamilton Chapman
Maciej Krysztofiak
Frank Lehmann
zunda
Dimitri Bouniol
Ahmed Elmoughazy
Martin Fitzka-Reichart
Thomas Pockrandt
Max Alexander