> On Mar 16, 2017, at 4:12 PM, Itai Ferber <[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
