I'd rather like let bar = foo as (a:c:)
to limit the possibility of bar not uncleared way. > >> 在 2016年7月7日，12:11，Félix Cloutier <[email protected]> 写道： >> >> I personally find that { foo(a: $0, c: $1) } is an already simple enough way >> to solve that problem. >> >> Félix >> >>> Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution >>> <[email protected]> a écrit : >>> >>> l'd like the way of Python to handle the function signature.Assign lost >>> other possibility of that function: >>> >>> foo(b:c:) >>> foo(a:c:) >>> foo(a:b:) >>> foo(a:) >>> foo(b:) >>> foo(c:) >>> foo() >>> >>> very weird. >>> >>> >>> >>>>> 在 2016年7月7日，11:36，Douglas Gregor <[email protected]> 写道： >>>>> >>>>> >>>>> On Jul 6, 2016, at 8:34 PM, [email protected] wrote: >>>>> >>>>> so how you call bar and get default values for a, b, c? >>>> >>>> You don’t. >>>> >>>>> why lost default value for that function? it is wired. >>>> >>>> Default values aren’t part of a function type. While it is possible to >>>> come up with such designs, there is little precedent for them and doing so >>>> either drastically limits what kinds of default arguments can be expressed >>>> or causes values of function type to become large (so they can encode the >>>> computation of the default values). >>>> >>>> - Doug >>>> >>>>> >>>>>>> 在 2016年7月7日，11:29，Douglas Gregor <[email protected]> 写道： >>>>>>> >>>>>>> >>>>>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Don't agree with this one. >>>>>>> >>>>>>> func foo(a: Int = 0, b: Int = 1, c: Int = 2) { >>>>>>> print(a, b, c) >>>>>>> } >>>>>>> >>>>>>> foo(a: 1, c: 3) >>>>>>> >>>>>>> let bar = foo >>>>>>> >>>>>>> bar(1, 3) will different than foo(a: 1, c: 3) >>>>>> >>>>>> bar(1, 3) will result in an error, because “bar” is of type >>>>>> >>>>>> (Int, Int, Int) -> Void >>>>>> >>>>>> Default arguments are associated with function declarations, not >>>>>> function types. >>>>>> >>>>>> - Doug >>>>>> >>>>>> >>>>>>> >>>>>>>> 在 2016年7月7日，11:06，Chris Lattner <[email protected]> 写道： >>>>>>>> >>>>>>>> Proposal Link: >>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md >>>>>>>> >>>>>>>> The review of "SE-0111: Remove type system significance of function >>>>>>>> argument labels " ran from June 30 ... July 4, 2016. The proposal has >>>>>>>> been *accepted*: >>>>>>>> >>>>>>>> The community and core team agree that this proposal will lead to a >>>>>>>> simplification and clarification of the type system, as well as a more >>>>>>>> clear user model for parameter labels. In response to community >>>>>>>> feedback, the core team is accepting the proposal with a revision to >>>>>>>> allow “purely cosmetic” parameter labels in closure types for >>>>>>>> documentation (as outlined in the alternatives section). The core >>>>>>>> team also wants to clarify that a call to a value of closure type >>>>>>>> would not allow use of any parameter labels, some interpretations >>>>>>>> thought that “arbitrary” parameter labels could be used. >>>>>>>> >>>>>>>> Thank you to Austin Zheng for driving this discussion forward! I >>>>>>>> filed SR-2009 to track implementation work on this. >>>>>>>> >>>>>>>> -Chris Lattner >>>>>>>> Review Manager >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution-announce mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
