One point of concern with making the implementations rely on that: it would require any adopter of Codable to be built in swift 4 mode no? it might be valuable to keep the protocol not requiring Swift 4 to aide in incremental migration.
> On Mar 16, 2017, at 2:14 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >> On Mar 16, 2017, at 4:12 PM, Itai Ferber <[email protected] >> <mailto:[email protected]>> wrote: >> >> If throwing subscripts made it in the Swift 4 timeframe, then we would >> certainly consider it. >> > Cool. Any comment from the core team on whether this is a possibility? If > it is and nobody else wants to write a proposal I would be willing to do it. >> On 16 Mar 2017, at 13:19, Matthew Johnson wrote: >> >> >>> On Mar 16, 2017, at 3:01 PM, Itai Ferber <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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%7E%20%22subscript%20throw%22>; >>> for Apple folks, 28775436. >>> >> They don’t “help” but they do provide a more natural interface. If the >> Foundation team feels a more wordy interface is necessary that is ok. >> >> I specifically mentioned that they can’t throw yet. Throwing subscripts >> would make a good companion proposal if they could fit into the Swift 4 >> timeframe. If not, then yes we need a method rather than a subscript. But >> if we can get throwing subscripts into Swift 4, why not use Swift’s first >> class syntactic support for keyed access to keyed containers? >> >>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > 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
