[swift-evolution] [Review] Naming Functions with Argument Labels

[Andrew Bennett]

I'm a -1 because of the syntax, I think it's nice and concise, and
unambiguous, but while it's familiar to people used to ObjectiveC it's
closer to ObjectiveC syntax than it is Swift.

I would +1 this proposal if the syntax was like this:
    let fn1 = someView.insertSubview(_,aboveSubview:)
    let fn = someView.insertSubview(_,at:_) // optional _ if it's needed to
disambiguate

That syntax would allow it to be naturally extended to support partial
application (Like what Bartlomiej Cichosz suggests
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html>
):
    let t1 = someView.insertSubview(_ , aboveSubview:  ) // equivalent of
yours
    let t2 = someView.insertSubview(_ , aboveSubview:v1) // partial
application
    let t3 = someView.insertSubview(v0, aboveSubview:v1) // calling a
function

This syntax is not quite as concise, but is much less surprising and more
logical than yours:
    let u1 = someView.insertSubview( _*:* aboveSubview:   ) // yours
    let u2 = someView.insertSubview( _, aboveSubview: v1) // partial
application
    let u3 = someView.insertSubview(v0, aboveSubview: v1) // calling a
function

The first *:* in u1 is jarring and differs greatly from the expected
syntax. Whether the partial application syntax is adopted or not; the
delimiters are different to what you use when declaring or calling a
function, the exception doesn't seem necessary.


On Thu, Jan 14, 2016 at 10:05 AM, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jan 13, 2016, at 12:08 PM, Jérôme Duquennoy via swift-evolution <
> swift-evolution at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/4699fcd8/attachment.html>