[Proposal] Automating Partial Application via Wildcards

Evolution Discussion
21

…and to be fair, I've also seen a lot of complaints about Swift that there are too many syntaxes for forming function values, so I'm hesitant to introduce yet more. If we had an awesome design that could *replace* some of the existing use cases, that might be more compelling.

-Joe

···

On Feb 2, 2016, at 11:31 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 2, 2016, at 11:14 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

I know there is concern about overloading the semantics of `_` which is unfortunate as IMO it is the best symbol to serve as a placeholder. I wonder if there has been confusion about the semantics in practice in languages like Scala where it is used in both ways. Is there any evidence that this has been a problem?

Not a super scientific study, but if you google "scala underscore", several of the results on the first page indicate confusion or bewilderment:

Scala _ [underscore] magic · Anantha Kumaran <Redirect Notice;

What are all the uses of an underscore in Scala? - Stack ... <Redirect Notice;

Scala dreaded underscore - SlideShare <Redirect Notice;

underscore confusion | The Scala Programming Language <http://www.scala-lang.org/old/node/2916.html&gt;

22

Yeah, I'm with Greg—I don't think this saves much over an explicit closure with $N arguments. Another problem with '_' is that it's nonobvious what the boundaries of the closure should be. You can say that it's the enclosing function application, but in the AST, a method invocation is two function applications, so by that rule '_.foo(_)' would mean {{ $0.foo }($0)}, and every operator is a separate function call, so '_ + _ + _' would be '{{ $0 + $1 } + $0}', neither of which is likely to be expected. The { $N } syntax is almost as compact, and is both clearer and more general.

I generally agree that specific syntax for partial application is not necessary. The {} wrapping the closure is not burdensome enough to justify a special case feature for partial application.

However, I am not a huge fan of the $N placeholder syntax. It looks noisy and also gets lost in the rest of the expression much more than underscore(s). `_` leaves visual “whitespace” which makes the “hole” in the expression stand out.

I know there is concern about overloading the semantics of `_` which is unfortunate as IMO it is the best symbol to serve as a placeholder. I wonder if there has been confusion about the semantics in practice in languages like Scala where it is used in both ways. Is there any evidence that this has been a problem?

I would like to see us consider switching to the the approach Dave posted:

Other systems have used “_”, and, for reordering parameters, “_0”,
“_1”, ...

let partial1 = f(arg1: 1, arg2: _) // { f(arg1: 1, arg2: $0) }
let partial2 = f(arg1: _1, arg2: _0) // { f(arg1: $1, arg2: $0) }

Naked `_` would refer arguments in syntactic order, and could perhaps be limited to “partial application” style closures and single-argument closures. In other cases `_N` would be used rather than `$N`.

-Matthew

···

On Feb 2, 2016, at 12:59 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

-Joe

On Feb 2, 2016, at 10:41 AM, Greg Titus via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What about $N? :-)

And then you could also put {} around it so that it is more obvious that partial1 is being assigned something that acts like a closure, and then you end up with:

let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) }
let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) }

instead of:

let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: _)
let partial2 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: _, x: _)

I’m -1.

With the way that single expression closures work, and the fact that they are so syntactically light, I don’t think that this proposal would add utility, it would just be one more construct to learn.

  - Greg

On Feb 2, 2016, at 10:28 AM, Gwendal Roué via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What about nothing?

let partial1 = f(arg1: 1, arg2:)
Gwendal

Le 2 févr. 2016 à 19:26, Gwendal Roué <gwendal.roue@gmail.com <mailto:gwendal.roue@gmail.com>> a écrit :

Any operator character would be bad, since the function may accept it, as in `[1,2,3].reduce(1, combine: *)`

Gwendal

Le 2 févr. 2016 à 19:24, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

On Feb 2, 2016, at 11:20 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Feb 2, 2016, at 10:16 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

One superficial comment on this: the use of _ here is a bad idea. _ already means something in expressions - “discard”, and a closely related thing in declarations - “ignore”.

Adding a third very different thing (placeholder to be filled in later) seems like a really confusing thing to do.

-Chris

#?

# means “macro like” or “compiler synthesized”.

-Chris

* would be bad, right? And naked ?-marks?

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

23

I know there is concern about overloading the semantics of `_` which is unfortunate as IMO it is the best symbol to serve as a placeholder. I wonder if there has been confusion about the semantics in practice in languages like Scala where it is used in both ways. Is there any evidence that this has been a problem?

Not a super scientific study, but if you google "scala underscore", several of the results on the first page indicate confusion or bewilderment:

Scala _ [underscore] magic · Anantha Kumaran <Redirect Notice;

What are all the uses of an underscore in Scala? - Stack ... <Redirect Notice;

Scala dreaded underscore - SlideShare <Redirect Notice;

underscore confusion | The Scala Programming Language <http://www.scala-lang.org/old/node/2916.html&gt;

Interesting. It looks like Scala takes this to a crazy extreme. I can definitely see why the core team is cautious about avoiding this mistake.

The example in the last link you shared is a pretty strong argument for avoiding partial application syntax (regardless of placeholder). It took me a minute to see what was happening there, while it would have been immediately clear with closure braces.

The thing I like about _ as a placeholder is the visual whitespace it leaves. It looks like a “hole” in the expression. I wish there was some other unclaimed symbol with that attribute.

It would be nice if we could find something better than $. The best argument in favor of that is precedent in other languages, but it comes at the cost of being noisy enough to impede readability IMO.

-Matthew

···

On Feb 2, 2016, at 1:31 PM, Joe Groff <jgroff@apple.com> wrote:

On Feb 2, 2016, at 11:14 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

-Joe

24

After the removal of function currying in SE-0002, it seemed like partial application would be a sensible improvement to the general problem that function currying was trying to solve. Scala-like partial application was even mentioned as an alternative in that proposal.
I was even thinking of writing up a proposal for this myself.

Joe’s arguments and his links have me pretty quickly convinced that this isn’t a great direction for Swift, especially with underscores. Admittedly, this was always just a pure sugar feature, but I no longer think it has any redeeming qualities over Swift’s existing closure syntax with either $N parameters or named parameters.

Thanks for writing the proposal, Erica and Davide, but I’m -1 on this.

···

On Feb 2, 2016, at 1:31 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 2, 2016, at 11:14 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

I know there is concern about overloading the semantics of `_` which is unfortunate as IMO it is the best symbol to serve as a placeholder. I wonder if there has been confusion about the semantics in practice in languages like Scala where it is used in both ways. Is there any evidence that this has been a problem?

Not a super scientific study, but if you google "scala underscore", several of the results on the first page indicate confusion or bewilderment:

Scala _ [underscore] magic · Anantha Kumaran <Redirect Notice;

What are all the uses of an underscore in Scala? - Stack ... <Redirect Notice;

Scala dreaded underscore - SlideShare <Redirect Notice;

underscore confusion | The Scala Programming Language <http://www.scala-lang.org/old/node/2916.html&gt;

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

25

There are things in Scala that flummoxed me early on - the underscore is not one of them. It is just new syntax - similar to using $0 or something else that if you have not seen before or know what it is used for it throws you to begin with.

It can always be taken to the extreme in a straw man argument to make a point, but for me it was definitely not an issue.

···

On 2016-02-03, at 2:42:44, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 2, 2016, at 1:31 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Feb 2, 2016, at 11:14 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

I know there is concern about overloading the semantics of `_` which is unfortunate as IMO it is the best symbol to serve as a placeholder. I wonder if there has been confusion about the semantics in practice in languages like Scala where it is used in both ways. Is there any evidence that this has been a problem?

Not a super scientific study, but if you google "scala underscore", several of the results on the first page indicate confusion or bewilderment:

Scala _ [underscore] magic · Anantha Kumaran <Redirect Notice;

What are all the uses of an underscore in Scala? - Stack ... <Redirect Notice;

Scala dreaded underscore - SlideShare <Redirect Notice;

underscore confusion | The Scala Programming Language <http://www.scala-lang.org/old/node/2916.html&gt;

Interesting. It looks like Scala takes this to a crazy extreme. I can definitely see why the core team is cautious about avoiding this mistake.

The example in the last link you shared is a pretty strong argument for avoiding partial application syntax (regardless of placeholder). It took me a minute to see what was happening there, while it would have been immediately clear with closure braces.

The thing I like about _ as a placeholder is the visual whitespace it leaves. It looks like a “hole” in the expression. I wish there was some other unclaimed symbol with that attribute.

It would be nice if we could find something better than $. The best argument in favor of that is precedent in other languages, but it comes at the cost of being noisy enough to impede readability IMO.

-Matthew

-Joe

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

26

Much prefer the syntax suggested by Greg that uses {} and $n

···

On Wednesday, 3 February 2016, Greg Titus via swift-evolution < swift-evolution@swift.org> wrote:

What about $N? :-)

And then you could also put {} around it so that it is more obvious that
partial1 is being assigned something that acts like a closure, and then you
end up with:

let partial1 = { projectFunctionToCoordinateSystem(function:
mySinFunction, p0: p0, p1: p1, x: $0) }
let partial2 = { projectFunctionToCoordinateSystem(function:
mySinFunction, p0: .zero, p1: $0, x: $1) }

instead of:

let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction,
p0: p0, p1: p1, x: _)
let partial2 = projectFunctionToCoordinateSystem(function: mySinFunction,
p0: .zero, p1: _, x: _)

I’m -1.

With the way that single expression closures work, and the fact that they
are so syntactically light, I don’t think that this proposal would add
utility, it would just be one more construct to learn.

- Greg

On Feb 2, 2016, at 10:28 AM, Gwendal Roué via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

What about nothing?

let partial1 = f(arg1: 1, arg2:)

Gwendal

Le 2 févr. 2016 à 19:26, Gwendal Roué <gwendal.roue@gmail.com > <javascript:_e(%7B%7D,'cvml','gwendal.roue@gmail.com');>> a écrit :

Any operator character would be bad, since the function may accept it, as
in `[1,2,3].reduce(1, combine: *)`

Gwendal

Le 2 févr. 2016 à 19:24, Erica Sadun via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> a écrit :

On Feb 2, 2016, at 11:20 AM, Chris Lattner <clattner@apple.com > <javascript:_e(%7B%7D,'cvml','clattner@apple.com');>> wrote:

On Feb 2, 2016, at 10:16 AM, Erica Sadun <erica@ericasadun.com > <javascript:_e(%7B%7D,'cvml','erica@ericasadun.com');>> wrote:

One superficial comment on this: the use of _ here is a bad idea. _
already means something in expressions - “discard”, and a closely related
thing in declarations - “ignore”.

Adding a third very different thing (placeholder to be filled in later)
seems like a really confusing thing to do.

-Chris

#?

# means “macro like” or “compiler synthesized”.

-Chris

* would be bad, right? And naked ?-marks?

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
  -- Howard.

27

Closures having unlabeled arguments is a feature, IMO. Propagating labels through the function type system introduces type differences where there don't need to be.

-Joe

···

On Feb 2, 2016, at 3:03 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

In current Swift, this approach does not preserve argument labels :

let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) } // (CGFloat) -> CGPoint
let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) } // (CGPoint, CGFloat) -> CGPoint

must be called partial1(0.5), not partial1(x: 0.5), unless you go to some significant work, as in the following:

let partial1: (x: CGFloat) -> CGPoint = {
    projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0)
}

It's not that this is undoable, it's just ugly and laborious, things that are un-Swifty. You must decide a priori which arguments will be applied, and manually name those that will not.

Compare with, for example, an imaginary version that uses $$ to accomplish the same with less planning and greater win:

let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $$) // (x: CGFloat) -> CGPoint

I find it a lot cleaner, less crufty™ and nicer to use than jerry-rigging with a closure.

28

In current Swift, this approach does not preserve argument labels :

let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) } // (CGFloat) -> CGPoint
let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) } // (CGPoint, CGFloat) -> CGPoint

must be called partial1(0.5), not partial1(x: 0.5), unless you go to some significant work, as in the following:

let partial1: (x: CGFloat) -> CGPoint = {
    projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0)
}

It's not that this is undoable, it's just ugly and laborious, things that are un-Swifty. You must decide a priori which arguments will be applied, and manually name those that will not.

Compare with, for example, an imaginary version that uses $$ to accomplish the same with less planning and greater win:

let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $$) // (x: CGFloat) -> CGPoint

I find it a lot cleaner, less crufty™ and nicer to use than jerry-rigging with a closure.

-- E

···

On Feb 2, 2016, at 3:40 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

Much prefer the syntax suggested by Greg that uses {} and $n

On Wednesday, 3 February 2016, Greg Titus via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
What about $N? :-)

And then you could also put {} around it so that it is more obvious that partial1 is being assigned something that acts like a closure, and then you end up with:

let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) }
let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) }

instead of:

let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: _)
let partial2 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: _, x: _)

I’m -1.

With the way that single expression closures work, and the fact that they are so syntactically light, I don’t think that this proposal would add utility, it would just be one more construct to learn.

  - Greg

On Feb 2, 2016, at 10:28 AM, Gwendal Roué via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

What about nothing?

let partial1 = f(arg1: 1, arg2:)
Gwendal

Le 2 févr. 2016 à 19:26, Gwendal Roué <gwendal.roue@gmail.com <javascript:_e(%7B%7D,'cvml','gwendal.roue@gmail.com');>> a écrit :

Any operator character would be bad, since the function may accept it, as in `[1,2,3].reduce(1, combine: *)`

Gwendal

Le 2 févr. 2016 à 19:24, Erica Sadun via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> a écrit :

On Feb 2, 2016, at 11:20 AM, Chris Lattner <clattner@apple.com <javascript:_e(%7B%7D,'cvml','clattner@apple.com');>> wrote:

On Feb 2, 2016, at 10:16 AM, Erica Sadun <erica@ericasadun.com <javascript:_e(%7B%7D,'cvml','erica@ericasadun.com');>> wrote:

One superficial comment on this: the use of _ here is a bad idea. _ already means something in expressions - “discard”, and a closely related thing in declarations - “ignore”.

Adding a third very different thing (placeholder to be filled in later) seems like a really confusing thing to do.

-Chris

#?

# means “macro like” or “compiler synthesized”.

-Chris

* would be bad, right? And naked ?-marks?

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
  -- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

1 Like
29

Ultimately, I think we want argument labels to be part of the name, not half-part-of-the-name-half-part-of-the-type like they are today. In the pure-names model, you could plausibly be allowed to name closure variables with compound names:

let partial2(p1:x:) = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) }

-Joe

···

On Feb 2, 2016, at 3:58 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Feb 2, 2016, at 4:42 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Feb 2, 2016, at 3:03 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

In current Swift, this approach does not preserve argument labels :

let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) } // (CGFloat) -> CGPoint
let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) } // (CGPoint, CGFloat) -> CGPoint

must be called partial1(0.5), not partial1(x: 0.5), unless you go to some significant work, as in the following:

let partial1: (x: CGFloat) -> CGPoint = {
    projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0)
}

It's not that this is undoable, it's just ugly and laborious, things that are un-Swifty. You must decide a priori which arguments will be applied, and manually name those that will not.

Compare with, for example, an imaginary version that uses $$ to accomplish the same with less planning and greater win:

let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $$) // (x: CGFloat) -> CGPoint

I find it a lot cleaner, less crufty™ and nicer to use than jerry-rigging with a closure.

Closures having unlabeled arguments is a feature, IMO. Propagating labels through the function type system introduces type differences where there don't need to be.

-Joe

I'm not suggesting they do otherwise. I was saying that using closures for partial application vs scala-style currying has a cost, which makes them less desirable for this (partial) application.

30

I'm not suggesting they do otherwise. I was saying that using closures for partial application vs scala-style currying has a cost, which makes them less desirable for this (partial) application.

Regardless, I want to thank everyone who participated in this discussion and gave feedback both positive and negative.

Appreciatively, -- Erica

···

On Feb 2, 2016, at 4:42 PM, Joe Groff <jgroff@apple.com> wrote:

On Feb 2, 2016, at 3:03 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

In current Swift, this approach does not preserve argument labels :

let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) } // (CGFloat) -> CGPoint
let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) } // (CGPoint, CGFloat) -> CGPoint

must be called partial1(0.5), not partial1(x: 0.5), unless you go to some significant work, as in the following:

let partial1: (x: CGFloat) -> CGPoint = {
    projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0)
}

It's not that this is undoable, it's just ugly and laborious, things that are un-Swifty. You must decide a priori which arguments will be applied, and manually name those that will not.

Compare with, for example, an imaginary version that uses $$ to accomplish the same with less planning and greater win:

let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $$) // (x: CGFloat) -> CGPoint

I find it a lot cleaner, less crufty™ and nicer to use than jerry-rigging with a closure.

Closures having unlabeled arguments is a feature, IMO. Propagating labels through the function type system introduces type differences where there don't need to be.

-Joe

31

That would be awesome.

-- E

···

On Feb 2, 2016, at 5:34 PM, Joe Groff <jgroff@apple.com> wrote:

I'm not suggesting they do otherwise. I was saying that using closures for partial application vs scala-style currying has a cost, which makes them less desirable for this (partial) application.

Ultimately, I think we want argument labels to be part of the name, not half-part-of-the-name-half-part-of-the-type like they are today. In the pure-names model, you could plausibly be allowed to name closure variables with compound names:

let partial2(p1:x:) = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) }

-Joe

32

Ultimately, I think we want argument labels to be part of the name, not half-part-of-the-name-half-part-of-the-type like they are today.

I think this would be a good move, as it could help with a topic that I haven't seen discussed here before:
Mixing Swift with other languages.

The goal "Objective C without the C" is good as long as it is about syntax and safety, but compatibility with the "lingua franca" of programming imho should be considered an advantage.
I know about calling C-code from Swift, but haven't seen much information on the other direction so far, and afair, it wasn't mentioned in SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md&gt;

As argument labels are a concept that is not available in most languages, it would be nice if there was an easy way to move them into the function name.

Tino

33

I'd really love for labels to be part-of-the-name only. Is it worth starting a proposition for that for the 3.0 time frame?

···

On 03 Feb 2016, at 01:34, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Ultimately, I think we want argument labels to be part of the name, not half-part-of-the-name-half-part-of-the-type like they are today.

34

Yeah, it's worth discussion, though I don't know that we have bandwidth to get all the way there this year. This part of the type checker is deep in technical debt. You might reach out to Chris Willmore, who's been exploring this space internally.

-Joe

···

On Feb 3, 2016, at 3:51 PM, David Hart <david@hartbit.com> wrote:

On 03 Feb 2016, at 01:34, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Ultimately, I think we want argument labels to be part of the name, not half-part-of-the-name-half-part-of-the-type like they are today.

I'd really love for labels to be part-of-the-name only. Is it worth starting a proposition for that for the 3.0 time frame?

35

I’ve started a discussion on that topic. Could you bring some input to help me understand the problem in detail?

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009049.html

···

On 04 Feb 2016, at 01:06, Joe Groff <jgroff@apple.com> wrote:

On Feb 3, 2016, at 3:51 PM, David Hart <david@hartbit.com> wrote:

On 03 Feb 2016, at 01:34, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Ultimately, I think we want argument labels to be part of the name, not half-part-of-the-name-half-part-of-the-type like they are today.

I'd really love for labels to be part-of-the-name only. Is it worth starting a proposition for that for the 3.0 time frame?

Yeah, it's worth discussion, though I don't know that we have bandwidth to get all the way there this year. This part of the type checker is deep in technical debt. You might reach out to Chris Willmore, who's been exploring this space internally.

-Joe