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
