> On Mar 16, 2017, at 3:01 PM, Itai Ferber <[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 > > _______________________________________________ > swift-evolution mailing list > [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
