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

[Itai Ferber]

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~%20%22subscript%20throw%22); 
for Apple folks, 28775436.

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> 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
>> 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/20170316/7fd87271/attachment.html>