> On 23 Mar 2017, at 19:37, Ben Rimmington wrote:
>
>> On 22 Mar 2017, at 17:41, Itai Ferber wrote:
>>
>> What’s the use case that you were thinking of? KeyPaths could be useful in
>> the case where you don’t need to customize your key names, but cannot
>> represent a custom case like
>>
>> public struct Post {
>> var authorID: Int
>> var bodyText: String
>>
>> private enum CodingKeys : String, CodingKey {
>> case authorID = "author_id"
>> case bodyText = "body_text"
>> }
>> }
>> Or am I misunderstanding?
>>
>
> For custom names, the `CodingKeys` enum does seem like the best design,
> unless an attribute can be used.
>
> public struct Post : Codable {
> @codable(name: "author_id") var authorID: Int
> @codable(name: "body_text") var bodyText: String
> }
>
> If each `KeyPath` encapsulates the type information, the `decode` methods
> won't need a `type` parameter.
>
> /// Primitive decoding methods (for single-value and keyed containers).
> open class DecodingContainer<Root : Codable> {
> open func decode(for keyPath: KeyPath<Root, Bool>) throws -> Bool
> open func decode(for keyPath: KeyPath<Root, Int>) throws -> Int
> open func decode(for keyPath: KeyPath<Root, UInt>) throws -> UInt
> open func decode(for keyPath: KeyPath<Root, Float>) throws -> Float
> open func decode(for keyPath: KeyPath<Root, Double>) throws ->
> Double
> open func decode(for keyPath: KeyPath<Root, String>) throws ->
> String
> open func decode(for keyPath: KeyPath<Root, Data>) throws -> Data
> }
>
> /// Keyed containers inherit the primitive decoding methods.
> open class KeyedDecodingContainer : DecodingContainer {
> open func decode<Value : Codable>(for keyPath: KeyPath<Root,
> Value>) throws -> Value
> }
On second thought, "property behaviors"
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/034042.html>
could eventually allow the custom name to be stored in a `KeyPath` subclass.
Key paths would also need `LosslessStringConvertible` conformance. The current
design only has `CustomDebugStringConvertible` conformance.
-- Ben
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
