> On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution > <swift-evolution@swift.org> 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 > z...@waldowski.me <mailto:z...@waldowski.me> > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
