> On Mar 16, 2017, at 4:18 PM, Philippe Hausler <[email protected]> wrote: > > 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.
Yes, probably so. I would be disappointed if we allowed the design of Swift 4 features to be influenced by Swift 3.1 compatibility. > >> On Mar 16, 2017, at 2:14 PM, Matthew Johnson via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
