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

[Itai Ferber]

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> 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
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170316/5ae7a6d4/attachment-0001.html>