On Thu, Jan 14, 2016 at 10:05 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:
On Jan 13, 2016, at 12:08 PM, Jérôme Duquennoy via swift-evolution < > swift-evolution@swift.org> wrote:
* What is your evaluation of the proposal?
This proposal does solve a real problem.
I have one concern about that proposal though: this is solving a compiler
ambiguity, but I think it would introduce a "visual" ambiguity :
let variable = function(arg1, argName: arg2) // function call
let variable = function (_:, argName:) // assign function to a variable
Those who lines, despite being pretty close visually, are very different.
I have the feeling that it might make non-obvious pieces a bit harder to
read. That could reduce swift readability.
FWIW, there are no commas in the compound names of this proposal. That
last line should be:
let variable = function(_:argName:) // assign function to a variable
In the case where there is a first argument label, it is visually close:
let variable = function(foo:bar:)
one has to scan to the last ‘:’ to distinguish it from a call.
- Doug
Todays method (using a closure) is more verbose, but it is less ambiguous
visually I think.
I would be happy to have this possibility, but not at the cost of code
readability.
* Is the problem being addressed significant enough to warrant a change to
Swift?
As a developper, I didn't encounter that situation a lot : I assign
closures to variables much more than functions.
Nevertheless, the current situation sounds a bit like an incoherency
between the way swift identifies methods internally and the way the
developper can refer to methods. I am absolutely no expert in compilers,
but can that be a flaw that would become problematic later on ? Sorry, I
cannot say :-). But if it is, then the problem surely is significant enough
to be addressed.
* Does this proposal fit well with the feel and direction of Swift?
As explained before, I feel the syntax proposed in that evolution has a
cost on readability, as it makes two very different things very similar
visually.
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
I’ve read the discussion on swift-evolution and the final proposal on
GitHub.
I have to say that I didn't even found a syntax that I could propose to
avoid the visual ambiguity.
Jerome
Le 13 janv. 2016 à 18:16, Joe Groff via swift-evolution < > swift-evolution@swift.org> a écrit :
Hello Swift community,
The review of "Naming Functions with Argument Labels" begins now and runs
through January 10th. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md>
Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the
review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to
Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
More information about the Swift evolution process is available at
https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,
-Joe
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution