[swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Itai Ferber]

Hi Goffredo,

Unless I'm misunderstanding what you mean here, this is exactly what 
we're proposing with the API — anything `Encodable` can encode any 
type that is `Encodable` as a nested value:

```swift
struct Person : Codable {
     let name: String
     let address: Address
}

struct Address : Codable {
     let street: String
     let city: String
     let state: String
     let zipCode: Int
     let country: String
}

let address = Address(street: "1 Infinite Loop", city: "Cupertino", 
state: "CA", zipCode: 95014, country: "United States")
let person = Person(name: "John Doe", address: address)

let encoder = JSONEncoder()
let payload = try encoder.encode(person)
print(String(data: payload, encoding: .utf8)!) // => {"name": "John 
Doe", address: {"street": "1 Infinite Loop", ... } }

let decoder = JSONDecoder()
let decoded = try decoder.decode(Person.self, from: payload) // => 
Person(name: "John Doe", address: ...)
```

Or have I misunderstood you?

— Itai

On 26 Apr 2017, at 13:11, Goffredo Marocchi via swift-evolution wrote:

> Sent from my iPhone
>
>> On 26 Apr 2017, at 17:24, Tony Parker via swift-evolution 
>> <swift-evolution at swift.org> wrote:
>>
>> Hi Riley,
>>
>>> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution 
>>> <swift-evolution at swift.org> wrote:
>>>
>>> I’m sure this has already been discussed, but why are the methods 
>>> throwing NSErrors and not Enums? If I’m remembering correctly, the 
>>> original reason for this was because this was meant to be a part of 
>>> Foundation. Now that this is in the Standard Library, however, it 
>>> seems strange that we’re still using NSError.
>>>
>>> Second question that again I’m sure was asked and answered 
>>> already, but: why do we require implementations for each concrete 
>>> numeric type (Int, Int8, Int16, Float, etc), instead of using 
>>> protocols (such as the new Integer protocols)?
>>
>> To answer your second question, the reason is that using the protocol 
>> implies that all encoders and decoders must support anything that 
>> conforms to that protocol.
>
> Would this make it easier to transform nested JSON into a nested 
> object/struct? If so it could be useful, very useful.
>
>> We’re not sure this is a reasonable requirement. Many formats do 
>> not have any kind of support for arbitrary size integers, for 
>> example. Therefore, we felt it was best to limit it to a set of 
>> concrete types.
>>
>
> I honk we would be missing a trick, unless I am missing something 
> here, that was very powerful in libraries like Mantle for iOS: the 
> ability to translate a nested JSON object (some keys in the JSON 
> object having a JSON object as value, etc...) in an MTLModel subclass 
> composed of other MTLModel subclasses where doing the transformation 
> of the root object would call the right model needed to transform for 
> the child JSON objects.
> Working with Mantle is safe, rugged (it does not cause crashes if the 
> JSON file changes), and allows you to break the problem into chunks 
> and present a coherent simple view to the code that makes use of the 
> instance you created out of the JSON input. Reference: 
> https://github.com/Mantle/Mantle/blob/master/README.md
>
>
>> We could change our minds on this before we ship Swift 4, if we feel 
>> it was the wrong decision. Now that the proposals are accepted we 
>> will be landing these branches in master soon, which means everyone 
>> has a great chance to try it out and see how it feels in real world 
>> usage before it’s final.
>>
>> - Tony
>>
>>>
>>>> On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution 
>>>> <swift-evolution at swift.org> wrote:
>>>>
>>>> Proposal Link: 
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>>>
>>>> Hello Swift Community,
>>>>
>>>> The review of SE-0166 “Swift Archival & Serialization” ran from 
>>>> April 6...12, 2017. The proposal is accepted with some minor 
>>>> modifications. Specifically, the core protocols and types will be 
>>>> sunk down into the Swift standard library for more tight 
>>>> integration with the Swift language and compiler, and the 
>>>> operations specifically involving Foundation’s “Data” type 
>>>> will be removed. The proposal document has been updated with more 
>>>> detail. Thank you everyone for participating in this review!
>>>>
>>>> 	- Doug
>>>> 	Review Manager
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution


> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170426/8d1e7f15/attachment.html>