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

Matthew Johnson matthew at anandabits.com
Thu Mar 16 15:24:39 CDT 2017


> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution <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).

> 
> 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
> 
> _______________________________________________
> 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/cdc15a3f/attachment.html>


More information about the swift-evolution mailing list