> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > >> >> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On 16 Mar 2017, at 19:34, 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. >> >> 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.” - 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 >>> [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 > > _______________________________________________ > 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
