[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Fri Mar 17 11:14:19 CDT 2017

Hi Matt,

> On Mar 17, 2017, at 6:39 AM, Matt Diephouse via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I have two related questions:
> 
>   1. Why was Swift 4 chosen as the target release for adding archival and serialization?
> 
>   2. Given Swift compatibility requirements going forward, how much will the design of these APIs be able to change?

I responded to this partially elsewhere in this thread, but the summary is: Swift developers are working with archiving and serialization right now and they deserve a better API that they can use as soon as possible. The language will always continue to evolve and improve.

> 
> The overall impression I get from the APIs is that they’ve been shaped by the current limitations of Swift (a familiar constraint). There are a number of likely future improvements that would likely significantly benefit this proposal:
> 
>   1. Throwing subscripts, as mentioned here
> 
>   2. Improved generics, such that protocols could be used instead of abstract base classes
> 
>   3. Improved type inference, as mentioned previously in the thread about inferring return types
> 
>   4. Dynamism/reflection in whatever form Swift adds would be very closely related, but more general, potentially influencing this design
> 
> Some of these could lead to improved, non-additive APIs. Will the archival and serialization APIs be able to be updated in response to improvements like these?

Yes, that is the plan. Our job during every release is to take a look at our APIs and implementations and make them better. Often times that means adjusting to new language features and other library features as they are released.

Another thing to remember is that library features can help drive language features. By releasing API like this, we are providing great motivation to pick what language features are most important going forward.

- Tony

> 
>> On Mar 16, 2017, at 5:12 PM, Itai Ferber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> If throwing subscripts made it in the Swift 4 timeframe, then we would certainly consider it.
>> 
>> On 16 Mar 2017, at 13:19, Matthew Johnson wrote:
>> 
>> 
>>> On Mar 16, 2017, at 3:01 PM, Itai Ferber <iferber at apple.com <mailto:iferber at apple.com>> wrote:
>>> 
>>> Subscripts, by the way, would not help here, since they cannot throw. decode must be able to throw.
>>> SR-238 <https://bugs.swift.org/browse/SR-238?jql=text%20%7E%20%22subscript%20throw%22>; for Apple folks, 28775436.
>>> 
>> They don’t “help” but they do provide a more natural interface.  If the Foundation team feels a more wordy interface is necessary that is ok.
>> 
>> I specifically mentioned that they can’t throw yet.  Throwing subscripts would make a good companion proposal if they could fit into the Swift 4 timeframe.  If not, then yes we need a method rather than a subscript.  But if we can get throwing subscripts into Swift 4, why not use Swift’s first class syntactic support for keyed access to keyed containers?
>> 
>>> On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote:
>>> 
>>> 
>>> 
>>>> On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote:
>>>>> I don’t have an example but I don’t see a problem either.  There are two options for specifying the return type manually.  We can use the signature you used above and use `as` to specify the expected type:
>>>>> 
>>>>> let i = decode(.myKey) as Int
>>>> 
>>>> The awkwardness of this syntax is exactly what I'm referring to. Would a beginner know to use "as Int" or ": Int"? Why would they? The "prettiness" of the simple case doesn't make up for how difficult it is to understand and fix its failure cases.
>>>> 
>>>> Any official Swift or Foundation API shouldn't, or shouldn't need to, make use of "tricky" syntax.
>>> 
>>> I don’t think this is especially tricky.  Nevertheless, we can avoid requiring this syntax by moving the type argument to the end and providing a default.  But I think return type inference is worth supporting.  It has become widely adopted by the community already in this use case.
>>> 
>>>> 
>>>>> If we don’t support this in Foundation we will continue to see 3rd party libraries that do this.
>>>> 
>>>> The proposal's been out for less than 24 hours, is it really productive to already be taking our ball and go home over such a minor thing?
>>> 
>>> I don’t think that’s what I’m doing at all.  This is a fantastic proposal.  I’m still working through it and writing up my more detailed thoughts.
>>> 
>>> That said, as with many (most?) first drafts, there is room for improvement.  I think it’s worth pointing out the syntax that many of us would like to use for decoding and at least considering including it in the proposal.  If the answer is that it’s trivial for those who want to use subscripts to write the wrappers for return type inference and / or subscripts themselves that’s ok.  But it’s a fair topic for discussion and should at least be addressed as an alternative that was rejected for a specific reason.
>>> 
>>>> 
>>>> Zach Waldowski
>>>> zach at waldowski.me <mailto:zach at waldowski.me>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20170317/e51e4b14/attachment.html>