> On Mar 16, 2017, at 1:06 PM, David Hart via swift-evolution > <[email protected]> wrote: > > > On 16 Mar 2017, at 16:53, Zach Waldowski <[email protected] > <mailto:[email protected]>> wrote: > >>> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
