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

[Matthew Johnson]

> On Mar 16, 2017, at 1:06 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> On 16 Mar 2017, at 16:53, Zach Waldowski <zach at waldowski.me <mailto:zach at waldowski.me>> wrote:
> 
>>> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal <https://github.com/utahiosmac/Marshal>) and Unbox (https://github.com/JohnSundell/Unbox <https://github.com/JohnSundell/Unbox>) don’t require the decoding functions to provide the type: those functions are generic on the return turn and it’s automatically inferred:
>>> 
>>> func decode<T>(key: Key) -> T
>>> 
>>> self.stringProperty = decode(key: .stringProperty) // correct specialisation of the generic function chosen by the compiler
>>> 
>>> Is there a reason the proposal did not choose this solution? Its quite sweet.
>> 
>> IMHO those are only “sweet” until you need to decode a value out to something other than a typed value, then it’s ambiguity city.
> 
> Other than a typed value? Can you give an example?

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

We can also use the type argument but provide a default value:

func decode<T>(_ key: Key, as type: T.Type = T.self) throws -> T

let i = decode(key: .myKey, as: Int.self)

I think the Foundation team should strongly consider one of these signatures and allow us to rely on return type inference when desired.  If this isn’t provided by Foundation we’ll see a bunch of wrappers that do this.  Why not include it in the standard interface?  

The same argument can be made for providing a subscript instead of or in addition to `decode`.  Of course exposing a proper subscript interface isn’t possible until we have throwing subscripts.  Decoding is one of the major motivating use cases for throwing subscripts.  With Foundation tackling this topic in Swift 4 maybe it would be good to consider bringing throwing subscripts in scope and using them in the interface to KeyedDecodingContainer.  

Subscript with return type inference is the natural interface for a keyed decoder (obviously IMO).  If we don’t support this in Foundation we will continue to see 3rd party libraries that do this.  I think it would be better to provide the same interface and implementation to everyone directly in Foundation itself.

> 
>> There are many ways to solve that, but none of them are conducive to beginners. Using the metatype to seed the generic resolution is the only thing I’d get behind, personally.
>> 
>> 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

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