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

[Matthew Johnson]

> On Mar 16, 2017, at 3:27 PM, Tony Parker <anthony.parker at apple.com> wrote:
> 
> 
>> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On 16 Mar 2017, at 19:34, 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.
>>> 
>>> Two arguments:
>>> 
>>> 1) Most of the time, you will be setting the return value of decode into a typed property and will not need ‘as’.
>>> 2) Even when you do need it, its not tricky syntax: it’s the official way to direct the type inference engine in Swift.
>> 
>> +1 to both of David’s points.  Needing to explicitly resolve ambiguity during decoding is pretty rare.  When necessary the syntax is perfectly reasonable.  Swift users who don’t understand single statement inference works and how to guide the inference engine should learn about these topics sooner or later.  It won’t be a hard topic to search if a user runs into trouble either.  
>> 
>> Nevertheless, if the Foundation team is strongly opposed to this many of us will just write our own wrappers.  This isn’t hard but it makes Swift code less consistent throughout the community.  Supporting consistent usage throughout the community seems like a reasonable goal to me.  IMO that means not leaving obvious expressivity gaps that are easy to fill.  In this case, there is a very good reason why we prefer subscripts and return type inference.  It makes our code much more clear by omitting a bunch of needless and noisy words (which is one of the principles of the API Design Guidelines).
>> 
> 
> Hi Matthew,
> 
> While fully acknowledging that the proposed API adds some “wordiness", I would also like to point out that the Swift API guidelines also explicitly state a goal to avoid overloading on return type:
> 
> "Lastly, avoid “overloading on return type” because it causes ambiguities in the presence of type inference.”

Fair enough.  I think that’s *usually* a great guideline.  However, in this specific use case I strongly support return type inference as a design that increases clarity while ambiguity is very rare in practice.  In any case, it sounds like the Foundation team has a pretty firm opinion on this topic.  I’ve offered my two cents and will let it drop now. :)

> 
> - Tony
> 
>>> David.
>>> 
>>>>> 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?
>>>> 
>>>> 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 <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/7c53e0b6/attachment.html>