Enable handling of types that require validation#13
Conversation
ianpartridge
left a comment
There was a problem hiding this comment.
I think we should have an example showing how to make types with failable initializers decodable. e.g.:
struct Animal {
let species: String
init?(species: String) {
if species.isEmpty { return nil }
self.species = species
}
}|
@ianpartridge I believe that example works with Codable already (as the |
ianpartridge
left a comment
There was a problem hiding this comment.
Thanks. I think we just need a few more comments in the examples. Also, should we call this Valid instead of Dummy?
|
Yes, the Decoder could give you a hint that the type may require conformance to those protocols (and we'd be able to give the exact name ie. Keyed or Single as we know the context). My intention was to also keep track of the most recent key that we were asked to decode, and the dummy value we provided - however, it occurred to me that this won't work in general, as the implementation of |
|
@ianpartridge Docs look fine locally, so this is ready to be merged once Travis completes |
|
This looks excellent, thank you. |
Description
This PR makes the
DummyCodingValueProviderandDummyKeyedCodingValueProviderprotocols public, for use with user types that validate field values during theinit(from: Decoder)initializer.The types have been renamed to
ValidSingleCodingValueProviderandValidKeyedCodingValueProvider, respectively.Motivation and Context
As part of the process of 'discovering' the type information for a Swift type, TypeDecoder creates an instance of the type by supplying dummy values for fields.
This works fine for types that do not validate the specific values of those fields, however there are cases where this scheme does not work - for example with Foundation types such as URL, where instance creation will fail if the string value provided does not have valid syntax.
To cater for those specific Foundation types, TypeDecoder has a pair of protocols:
DummyCodingValueProviderandDummyKeyedCodingValueProvider, that allow an extension of a type to declare conformant ('dummy') values while simulating decoding. However, these are currently not public and so user types are unable to use this method.We considered requiring users to break the decoding and validation process into two parts: leaving the
init(from: Decoder)to mechanically decode the values, and then have a separateValidatableprotocol which can be conformed to, which would house the validation logic. Kitura would then requie avalidate()function to succeed before passing a Codable type through to the user's route handler.However, this is insufficient for two reasons:
enumis declared with a String raw value (eg:enum Colour: String, Codable), the compiler will automatically synthesize aninit(from: Decoder)implementation that performs validation on the values being passed in (to ensure they match one of the declared cases).The solution proposed here is to require such validating types to be extended with a conformance to the appropriate protocol above, in order to supply valid dummy values.