Hey Charlie,
The change you reference and this must work together, I have a hard time
accepting that we will have a Swift 3 with this change in and no other change
that balances it.
If this
function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {
[...]
callback(20,40, true)
}
is the style we have to use with callbacks from now on, it will be a major
regression I would advise a proposal to stop right now.
The closure passed around and arriving as a callback there gives me NO clue how
to send data to it. How is that for local reasoning?
This makes me believe/hope that I am getting it all wrong, so please correct me
here :D.
If it is not true, then I am blowing things out of proportion and I apologise
for this to everyone on the list.
Sent from my iPhone
> On 7 Jul 2016, at 08:41, Charlie Monroe <[email protected]> wrote:
>
> There was a fair proposal by Brent
> (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding
> the labels to the name of the variable rather than adding it to the type. And
> I agree with that since it simplifies the type system.
>
> Unfortunately, since Swift 3 is making all the code-breaking changed and
> Brent's counterproposal is additive, it leaves at least a year-long period of
> not having the parameter labels in closures.
>
> I agree with the change, I don't agree with the timing where it doesn't have
> a replacement yet.
>
>> On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution
>> <[email protected]> wrote:
>>
>> This feels like making the language a lot worse. Lots of time was recently
>> spent bikeshedding methods names and argument labels and this proposal bans
>> labels use in some cases and encourage people not to use them in others.
>>
>>> On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> func needsCallback(callback: (a: Int, b: Int) -> Void) {
>>> callback(a: 1,b: 2)
>>> }
>>>
>>>
>>> func needsCallback(callback: (Int, Int) -> Void) {
>>> callback(1, 2)
>>> }
>>>
>>> Is the first one will be forbidden?
>>> So you'd like to keep the second one?
>>
>> I do not understand why someone would want the second example. A great point
>> of both Objective-C and Swift was enforcing parameter labels use to make the
>> code more readable.
>>
>> What if that callback were to need width and height? How is that clear which
>> parameter I need to pass in which order?
>>
>> Considering Swift 3 is our last big chance to break code and fixing the
>> effects of this proposal would break quite a bit of code again... this is a
>> choice it would impact the language for a long time.
>>
>>
>>>> 在 2016年7月7日，11:06，Chris Lattner via swift-evolution
>>>> <[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 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
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
