> On Mar 16, 2017, at 3:27 PM, Tony Parker <anthony.par...@apple.com> wrote: > > >> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>>> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution >>>> <swift-evolution@swift.org <mailto: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. >>> >>> Two arguments: >>> >>> 1) Most of the time, you will be setting the return value of decode into a >>> typed property and will not need ‘as’. >>> 2) Even when you do need it, its not tricky syntax: it’s the official way >>> to direct the type inference engine in Swift. >> >> +1 to both of David’s points. Needing to explicitly resolve ambiguity >> during decoding is pretty rare. When necessary the syntax is perfectly >> reasonable. Swift users who don’t understand single statement inference >> works and how to guide the inference engine should learn about these topics >> sooner or later. It won’t be a hard topic to search if a user runs into >> trouble either. >> >> Nevertheless, if the Foundation team is strongly opposed to this many of us >> will just write our own wrappers. This isn’t hard but it makes Swift code >> less consistent throughout the community. Supporting consistent usage >> throughout the community seems like a reasonable goal to me. IMO that means >> not leaving obvious expressivity gaps that are easy to fill. In this case, >> there is a very good reason why we prefer subscripts and return type >> inference. It makes our code much more clear by omitting a bunch of >> needless and noisy words (which is one of the principles of the API Design >> Guidelines). >> > > Hi Matthew, > > While fully acknowledging that the proposed API adds some “wordiness", I > would also like to point out that the Swift API guidelines also explicitly > state a goal to avoid overloading on return type: > > "Lastly, avoid “overloading on return type” because it causes ambiguities in > the presence of type inference.”
Fair enough. I think that’s *usually* a great guideline. However, in this specific use case I strongly support return type inference as a design that increases clarity while ambiguity is very rare in practice. In any case, it sounds like the Foundation team has a pretty firm opinion on this topic. I’ve offered my two cents and will let it drop now. :) > > - Tony > >>> David. >>> >>>>> 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? >>>> >>>> Zach Waldowski >>>> z...@waldowski.me <mailto:z...@waldowski.me> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
