Here are the pull requests to cc yourself on:

The compiler and standard library part:

https://github.com/apple/swift/pull/9004 
<https://github.com/apple/swift/pull/9004>

The Foundation part:

https://github.com/apple/swift/pull/9005 
<https://github.com/apple/swift/pull/9005>

- Tony

> On Apr 26, 2017, at 9:26 AM, Shawn Erickson <[email protected]> wrote:
> 
> Can you ping the list when aspects of this work lands in master? I have real 
> world code that I want to see how this new stuff shakes out when attempting 
> to use.
> 
> On Wed, Apr 26, 2017 at 9:24 AM Tony Parker via swift-evolution 
> <[email protected] <mailto:[email protected]>> wrote:
> Hi Riley,
> 
>> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution 
>> <[email protected] <mailto:[email protected]>> 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. 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.
> 
> 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 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> Proposal Link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>>  
>>> <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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to