Referencing zero-parameter functions


(Alex Hoppen) #1

The idea of adding a syntax to reference zero-argument functions just like foo(arg:) is used to reference a one-parameter function has come up several times on the list. Pyry and I have put together a proposal to let foo(_) refer to a function foo without any parameters. GitHub-Link: https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/0000-refernce-zero-param-func.md

Comments welcome, especially if someone thinks that any of the issues listed in "Possible issues" are major or sees any other problems.

– Alex

Referencing zero-parameter functions

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author(s): Alex Hoppen <https://github.com/ahoppen>, Pyry Jahkola <https://github.com/pyrtsa>
Status: Draft
Review manager: TBD
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#introduction>Introduction

Since the approval of SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> it is possible to reference a function by its argument names using the foo(arg:) syntax but there is no way to reference a zero-parameter function. This proposal adds a new syntax foo(_) to reference an overloaded function with zero parameters.

This was one point in the discussion: [Pitch] Richer function identifiers, simpler function types <http://thread.gmane.org/gmane.comp.lang.swift.evolution/15577/>
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#motivation>Motivation

Consider the following example

class Bar {
  func foo() {
  }

  func foo(arg: Int) {
  }
}
You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no syntax to reference foo() without using disambiguation by type Bar.foo() as () -> Void. We believe this is a major hole in the current disambiguation syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#proposed-solution>Proposed solution

We propose that Bar.foo(_) references the function with no parameters just as Bar.foo(arg:) references the function with one argument named arg.

In the context of functions declarations _ already has the meaning of "there is nothing" (e.g. func foo(_ arg: Int)). Thus, we believe that _ is the right character to mean that a function has no parameters.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#detailed-design>Detailed design

The unqualified-name grammar rule from SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> changes to

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
                  > identifier '(_)'
If two overloads with zero-parameters exist with different return types, disambiguation has still to be done via as just like with the foo(arg:) syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#impact-on-existing-code>Impact on existing code

This is a purely additive feature and has no impact on existing code.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#possible-issues>Possible issues

If Swift should ever support out-only parameters Bar.foo(_) could mean that the only out-only parameter shall be ignored. This would clash with the currently proposed syntax. However, since Swift functions may return multiple values as a tuple, we don't see this coming.

Bar.foo(_) may be mistaken for Bar.foo(_:slight_smile: if there is also a one-parameter function without a label. This mistake would, however, be mostly detected by the compiler when later calling the function with an argument.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternatives-considered>Alternatives considered

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-1-barfoo>Alternative 1: Bar.foo

Let Bar.foo reference the function with zero parameters only. While this works around the possible issue of ignored out-only parameters described above, this has several minor drawbacks to the proposed solution (some of these drawbacks are mutually exclusive based on possible future proposals but one always applies):

Most functions are not overloadad and using the base name only offers a shorthand way to reference these functions.
This would block the way of allowing properties with the same name as a function with zero parameters by banning Bar.foo as a function reference (could be another proposal once this one is accepted).
Bar.foo(arg:) hints that a function is referenced by its paranthesis. Bar.foo doesn't include paranthesis, which causes a subtle inconsistency.
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-2-barfoo-inside-selector>Alternative 2: Bar.foo() inside #selector

Let Bar.foo() refer to the zero-parameter function only inside #selector as it was proposed by Doug Gregor here <https://github.com/apple/swift-evolution/pull/280#discussion_r61849122>. This requires the proposal to disallow arbitrary expressions in #selector (GitHub-Link <https://github.com/ahoppen/swift-evolution/blob/arbitrary-expressions-in-selectors/proposals/0000-arbitrary-expressions-in-selectors.md>) to be approved. Issues we see are:

This gives the illusion that foo is actually called which it isn't
It doen't solve the issue of referncing a zero-parameter function in arbitrary expressions somewhere else in code.
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#future-directions>Future directions

If this proposal is accepted there is no need that Bar.foo references a function with base name foo since there is a notation with paranthesis for every argument constellation. We could disallow Bar.foo to reference a function and allow a property named foo on Bar. Bar.foo would then refer to this property.


(David Sweeris) #2

What’s wrong with `foo()` again? To me, a `_` in the parameter list means that something is there, but the label doesn’t matter.

- Dave Sweeris

···

On May 5, 2016, at 9:42 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

The idea of adding a syntax to reference zero-argument functions just like foo(arg:) is used to reference a one-parameter function has come up several times on the list. Pyry and I have put together a proposal to let foo(_) refer to a function foo without any parameters. GitHub-Link: https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/0000-refernce-zero-param-func.md

Comments welcome, especially if someone thinks that any of the issues listed in "Possible issues" are major or sees any other problems.

– Alex

Referencing zero-parameter functions

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author(s): Alex Hoppen <https://github.com/ahoppen>, Pyry Jahkola <https://github.com/pyrtsa>
Status: Draft
Review manager: TBD
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#introduction>Introduction

Since the approval of SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> it is possible to reference a function by its argument names using the foo(arg:) syntax but there is no way to reference a zero-parameter function. This proposal adds a new syntax foo(_) to reference an overloaded function with zero parameters.

This was one point in the discussion: [Pitch] Richer function identifiers, simpler function types <http://thread.gmane.org/gmane.comp.lang.swift.evolution/15577/>
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#motivation>Motivation

Consider the following example

class Bar {
  func foo() {
  }

  func foo(arg: Int) {
  }
}
You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no syntax to reference foo() without using disambiguation by type Bar.foo() as () -> Void. We believe this is a major hole in the current disambiguation syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#proposed-solution>Proposed solution

We propose that Bar.foo(_) references the function with no parameters just as Bar.foo(arg:) references the function with one argument named arg.

In the context of functions declarations _ already has the meaning of "there is nothing" (e.g. func foo(_ arg: Int)). Thus, we believe that _ is the right character to mean that a function has no parameters.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#detailed-design>Detailed design

The unqualified-name grammar rule from SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> changes to

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
                  > identifier '(_)'
If two overloads with zero-parameters exist with different return types, disambiguation has still to be done via as just like with the foo(arg:) syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#impact-on-existing-code>Impact on existing code

This is a purely additive feature and has no impact on existing code.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#possible-issues>Possible issues

If Swift should ever support out-only parameters Bar.foo(_) could mean that the only out-only parameter shall be ignored. This would clash with the currently proposed syntax. However, since Swift functions may return multiple values as a tuple, we don't see this coming.

Bar.foo(_) may be mistaken for Bar.foo(_:slight_smile: if there is also a one-parameter function without a label. This mistake would, however, be mostly detected by the compiler when later calling the function with an argument.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternatives-considered>Alternatives considered

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-1-barfoo>Alternative 1: Bar.foo

Let Bar.foo reference the function with zero parameters only. While this works around the possible issue of ignored out-only parameters described above, this has several minor drawbacks to the proposed solution (some of these drawbacks are mutually exclusive based on possible future proposals but one always applies):

Most functions are not overloadad and using the base name only offers a shorthand way to reference these functions.
This would block the way of allowing properties with the same name as a function with zero parameters by banning Bar.foo as a function reference (could be another proposal once this one is accepted).
Bar.foo(arg:) hints that a function is referenced by its paranthesis. Bar.foo doesn't include paranthesis, which causes a subtle inconsistency.
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-2-barfoo-inside-selector>Alternative 2: Bar.foo() inside #selector

Let Bar.foo() refer to the zero-parameter function only inside #selector as it was proposed by Doug Gregor here <https://github.com/apple/swift-evolution/pull/280#discussion_r61849122>. This requires the proposal to disallow arbitrary expressions in #selector (GitHub-Link <https://github.com/ahoppen/swift-evolution/blob/arbitrary-expressions-in-selectors/proposals/0000-arbitrary-expressions-in-selectors.md>) to be approved. Issues we see are:

This gives the illusion that foo is actually called which it isn't
It doen't solve the issue of referncing a zero-parameter function in arbitrary expressions somewhere else in code.
<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#future-directions>Future directions

If this proposal is accepted there is no need that Bar.foo references a function with base name foo since there is a notation with paranthesis for every argument constellation. We could disallow Bar.foo to reference a function and allow a property named foo on Bar. Bar.foo would then refer to this property.

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


(Alex Hoppen) #3

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`.

As to `_`: Like I stated in the proposal the underscore is already used in functions to state that there is no parameter name. So I think it’s a natural extension to also use it for saying that there are no arguments at all.

– Alex

···

On 05 May 2016, at 17:21, David Sweeris <davesweeris@mac.com> wrote:

What’s wrong with `foo()` again? To me, a `_` in the parameter list means that something is there, but the label doesn’t matter.

- Dave Sweeris


(Chris Lattner) #4

Right.

That said, what is wrong with just “foo”?

-Chris

···

On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`.


(Jordan Rose) #5

I agree with Xiaodi about the syntax. We should not use ‘_’ here for the same reason that we do use it for label-less parameters: it makes every argument always marked by at least two characters. That makes it easier to read and harder to typo.

I do see that there’s a problem between ‘foo()’ (a reference to a function with no arguments) and ‘foo()’ (the result of calling a function with no arguments).

I’m personally not so inclined to worry about the “reference to a function” syntax; I’ve ultimately fallen into the camp that prefers a wrapper closure in most cases. The selector case is a little different. If we ban general expressions there, then I think there’s no problem with it being mistaken for an actual call, because nothing in #selector would act like a call anyway. If we don’t, it’d still be unambiguous…but I agree that it could be confusing.

Jordan

···

On May 5, 2016, at 09:34, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

I disagree. Not having a parameter label implies presence of a parameter. It is not natural at all to use the same symbol to denote absence of a parameter. `foo(_)` is a single typo away from `foo(_:)`.

IMO, after arbitrary expressions are removed from #selector, it is straightforwardly a bug that `foo()` cannot be used to denote a function with no parameters.
On Thu, May 5, 2016 at 10:59 Alex Hoppen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`.

As to `_`: Like I stated in the proposal the underscore is already used in functions to state that there is no parameter name. So I think it’s a natural extension to also use it for saying that there are no arguments at all.

– Alex

> On 05 May 2016, at 17:21, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
>
> What’s wrong with `foo()` again? To me, a `_` in the parameter list means that something is there, but the label doesn’t matter.
>
> - Dave Sweeris
_______________________________________________
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


(Kurt Werle) #6

Yeah, that'd work. The problems:
* Name collisions with variables (not a big deal, I think)
* "foo" looks substantially different than "bar(baz:)", but they mean the
same thing

I prefer something like #foo(), #bar(baz:). Clearly that particular choice
can't work.

Kurt

···

On Thu, May 5, 2016 at 10:03 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution < > swift-evolution@swift.org> wrote:
> Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and
returns its return value of type `Int` – not a reference to the function of
type `Void -> Int`.

Right.

That said, what is wrong with just “foo”?

--
kurt@CircleW.org
http://www.CircleW.org/kurt/


(Jordan Rose) #7

As pointed out in the original post, that can refer to both ‘foo()’ and ‘foo(bar:)’ today.

Jordan

···

On May 5, 2016, at 10:03, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`.

Right.

That said, what is wrong with just “foo”?


(Joe Groff) #8

We could change that, so that to refer to `foo(bar:)` you must use the full compound name.

-Joe

···

On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 10:03, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`.

Right.

That said, what is wrong with just “foo”?

As pointed out in the original post, that can refer to both ‘foo()’ and ‘foo(bar:)’ today.


(Chris Lattner) #9

Right. that seems like the most logical solution to this problem, if it is really significant enough to fix.

-Chris

···

On May 5, 2016, at 10:38 AM, Joe Groff <jgroff@apple.com> wrote:

On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 10:03, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`.

Right.

That said, what is wrong with just “foo”?

As pointed out in the original post, that can refer to both ‘foo()’ and ‘foo(bar:)’ today.

We could change that, so that to refer to `foo(bar:)` you must use the full compound name.


(Xiaodi Wu) #10

I disagree. Not having a parameter label implies presence of a parameter.
It is not natural at all to use the same symbol to denote absence of a
parameter. `foo(_)` is a single typo away from `foo(_:)`.

IMO, after arbitrary expressions are removed from #selector, it is
straightforwardly a bug that `foo()` cannot be used to denote a function
with no parameters.

···

On Thu, May 5, 2016 at 10:59 Alex Hoppen via swift-evolution < swift-evolution@swift.org> wrote:

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and
returns its return value of type `Int` – not a reference to the function of
type `Void -> Int`.

As to `_`: Like I stated in the proposal the underscore is already used in
functions to state that there is no parameter name. So I think it’s a
natural extension to also use it for saying that there are no arguments at
all.

– Alex

> On 05 May 2016, at 17:21, David Sweeris <davesweeris@mac.com> wrote:
>
> What’s wrong with `foo()` again? To me, a `_` in the parameter list
means that something is there, but the label doesn’t matter.
>
> - Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Alex Hoppen) #11

That would be my second favourite option if there is no support for `foo(_)`, which there doesn’t seem to be. If there is support for letting `foo` refer to the zero-parameter function, I will change the proposal.

– Alex

···

On 05 May 2016, at 19:38, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 10:03, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`.

Right.

That said, what is wrong with just “foo”?

As pointed out in the original post, that can refer to both ‘foo()’ and ‘foo(bar:)’ today.

We could change that, so that to refer to `foo(bar:)` you must use the full compound name.

-Joe


(Xiaodi Wu) #12

Can I offer a more verbose alternative? How's `foo() -> _` for referring to
a zero-parameter function? It's clearly not a function call, and it says
you want to match regardless of what the return value is...

···

On Thu, May 5, 2016 at 1:06 PM, Alex Hoppen via swift-evolution < swift-evolution@swift.org> wrote:

> On 05 May 2016, at 19:38, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>>
>>> On May 5, 2016, at 10:03, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution < > swift-evolution@swift.org> wrote:
>>>> Say you have the function `foo() -> Int`. Then `foo()` calls `foo`
and returns its return value of type `Int` – not a reference to the
function of type `Void -> Int`.
>>>
>>> Right.
>>>
>>> That said, what is wrong with just “foo”?
>>
>> As pointed out in the original post, that can refer to both ‘foo()’ and
‘foo(bar:)’ today.
>
> We could change that, so that to refer to `foo(bar:)` you must use the
full compound name.
>
> -Joe

That would be my second favourite option if there is no support for
`foo(_)`, which there doesn’t seem to be. If there is support for letting
`foo` refer to the zero-parameter function, I will change the proposal.

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


(Alex Hoppen) #13

Thanks for your feedback so far. Based on the discussion, I have updated the proposal to let `foo` refer to the zero-parameter function instead of `foo(_)`.

The updated proposal is also available on GitHub: https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/0000-refernce-zero-param-func.md.

Again comments would be greatly appreciated.

– Alex

Referencing zero-parameter functions

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author(s): Alex Hoppen <https://github.com/ahoppen>, Pyry Jahkola <https://github.com/pyrtsa>
Status: Draft
Review manager: TBD

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#introduction>Introduction

Since the approval of SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> it is possible to reference a function by its argument names using the foo(arg:) syntax but there is no way to reference a zero-parameter function. foo currently references all methods with base name foo. If there are multiple methods with this base name, one has to disambiguate the referenced function by its type using as.

This proposal changes the behaviour of foo to always reference a zero-parameter function. To reference a function with more parameters, the argument labels have to be explicitly named (e.g. foo(arg:)).

Originally, the proposal sought to introduce the new syntax foo(_) to reference an overloaded function with zero parameters, but was discarded based on the discussion on swift-evolution <http://thread.gmane.org/gmane.comp.lang.swift.evolution/16150>.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#motivation>Motivation

Consider the following example

class Bar {
  func foo() {
  }

  func foo(arg: Int) {
  }
}
You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no syntax to reference foo() without using disambiguation by type Bar.foo as () -> Void. We believe this is a major hole in the current disambiguation syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#proposed-solution>Proposed solution

We propose that Bar.foo only references methods with no parameters just as Bar.foo(arg:) references the methods with one argument named arg.

This is a breaking change since Bar.foo currently refers to all methods with base name foo.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#detailed-design>Detailed design

The existing syntax Bar.foo is reinterpreted to not reference any method on Bar with base name foo but to only reference functions named foo that take no parameters.

If two overloads with zero-parameters exist with different return types, disambiguation has still to be done via as just like with the foo(arg:) syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#impact-on-existing-code>Impact on existing code

Existing code that uses Bar.foo to reference methods with parameters needs to be changed. We believe this will effect many developers, so a fix-it would be essential.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#possible-issues>Possible issues

Bar.foo may be mistaken for a reference to a property, since all other references to functions will contain parenthesis if this proposal is accepted.

Most functions are not overloaded and using the base name only offers a shorthand way to reference these functions. If this proposal is accepted, this shorthand is no longer available for methods with parameters.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternatives-considered>Alternatives considered

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-1-barfoo-inside-selector>Alternative 1: Bar.foo() inside #selector

Let Bar.foo() refer to the zero-parameter function only inside #selector as it was proposed by Doug Gregor here <https://github.com/apple/swift-evolution/pull/280#discussion_r61849122>. This requires the proposal to disallow arbitrary expressions in #selector (GitHub-Link <https://github.com/ahoppen/swift-evolution/blob/arbitrary-expressions-in-selectors/proposals/0000-arbitrary-expressions-in-selectors.md>) to be approved. Issues we see are:

This gives the illusion that foo is actually called which it isn't
It doesn't solve the issue of referencing a zero-parameter function in arbitrary expressions somewhere else in code.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-2-barfoo_>Alternative 2: Bar.foo(_)

The original idea of using Bar.foo(_) to refer to the zero-parameter method was discarded after discussion on the mailing list because of the following reasons:

It is only a single typo away from Bar.foo(_:slight_smile: which references the method with one unnamed argument
In argument lists _ implies the presence of an unnamed parameter, while _ in Bar.foo(_) would mark the absence of a any parameters.


(Douglas Gregor) #14

Thanks for your feedback so far. Based on the discussion, I have updated the proposal to let `foo` refer to the zero-parameter function instead of `foo(_)`.

The updated proposal is also available on GitHub: https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/0000-refernce-zero-param-func.md.

Again comments would be greatly appreciated.

General comment: now that this proposal has pivoted to always requiring the argument labels when referencing a function, the title and introduction are misleading. This is a *much* larger change than Alternative 1 or Alternative 2, and is now source-breaking.

(Personally, I still think “Alternative 1” is the right answer)

  - Doug

···

On May 6, 2016, at 12:34 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

– Alex

Referencing zero-parameter functions

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author(s): Alex Hoppen <https://github.com/ahoppen>, Pyry Jahkola <https://github.com/pyrtsa>
Status: Draft
Review manager: TBD

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#introduction>Introduction

Since the approval of SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> it is possible to reference a function by its argument names using the foo(arg:) syntax but there is no way to reference a zero-parameter function. foo currently references all methods with base name foo. If there are multiple methods with this base name, one has to disambiguate the referenced function by its type using as.

This proposal changes the behaviour of foo to always reference a zero-parameter function. To reference a function with more parameters, the argument labels have to be explicitly named (e.g. foo(arg:)).

Originally, the proposal sought to introduce the new syntax foo(_) to reference an overloaded function with zero parameters, but was discarded based on the discussion on swift-evolution <http://thread.gmane.org/gmane.comp.lang.swift.evolution/16150>.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#motivation>Motivation

Consider the following example

class Bar {
  func foo() {
  }

  func foo(arg: Int) {
  }
}
You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no syntax to reference foo() without using disambiguation by type Bar.foo as () -> Void. We believe this is a major hole in the current disambiguation syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#proposed-solution>Proposed solution

We propose that Bar.foo only references methods with no parameters just as Bar.foo(arg:) references the methods with one argument named arg.

This is a breaking change since Bar.foo currently refers to all methods with base name foo.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#detailed-design>Detailed design

The existing syntax Bar.foo is reinterpreted to not reference any method on Bar with base name foo but to only reference functions named foo that take no parameters.

If two overloads with zero-parameters exist with different return types, disambiguation has still to be done via as just like with the foo(arg:) syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#impact-on-existing-code>Impact on existing code

Existing code that uses Bar.foo to reference methods with parameters needs to be changed. We believe this will effect many developers, so a fix-it would be essential.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#possible-issues>Possible issues

Bar.foo may be mistaken for a reference to a property, since all other references to functions will contain parenthesis if this proposal is accepted.

Most functions are not overloaded and using the base name only offers a shorthand way to reference these functions. If this proposal is accepted, this shorthand is no longer available for methods with parameters.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternatives-considered>Alternatives considered

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-1-barfoo-inside-selector>Alternative 1: Bar.foo() inside #selector

Let Bar.foo() refer to the zero-parameter function only inside #selector as it was proposed by Doug Gregor here <https://github.com/apple/swift-evolution/pull/280#discussion_r61849122>. This requires the proposal to disallow arbitrary expressions in #selector (GitHub-Link <https://github.com/ahoppen/swift-evolution/blob/arbitrary-expressions-in-selectors/proposals/0000-arbitrary-expressions-in-selectors.md>) to be approved. Issues we see are:

This gives the illusion that foo is actually called which it isn't
It doesn't solve the issue of referencing a zero-parameter function in arbitrary expressions somewhere else in code.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-2-barfoo_>Alternative 2: Bar.foo(_)

The original idea of using Bar.foo(_) to refer to the zero-parameter method was discarded after discussion on the mailing list because of the following reasons:

It is only a single typo away from Bar.foo(_:slight_smile: which references the method with one unnamed argument
In argument lists _ implies the presence of an unnamed parameter, while _ in Bar.foo(_) would mark the absence of a any parameters.

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


(Alex Hoppen) #15

Since there doesn’t seem to be much support for the proposal, I’ll drop it and incorporate Alternative 1 into the #selector proposal like Doug suggested.

– Alex

···

On 12 May 2016, at 20:52, Douglas Gregor <dgregor@apple.com> wrote:

On May 6, 2016, at 12:34 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks for your feedback so far. Based on the discussion, I have updated the proposal to let `foo` refer to the zero-parameter function instead of `foo(_)`.

The updated proposal is also available on GitHub: https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/0000-refernce-zero-param-func.md.

Again comments would be greatly appreciated.

General comment: now that this proposal has pivoted to always requiring the argument labels when referencing a function, the title and introduction are misleading. This is a *much* larger change than Alternative 1 or Alternative 2, and is now source-breaking.

(Personally, I still think “Alternative 1” is the right answer)

  - Doug

– Alex

Referencing zero-parameter functions

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author(s): Alex Hoppen <https://github.com/ahoppen>, Pyry Jahkola <https://github.com/pyrtsa>
Status: Draft
Review manager: TBD

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#introduction>Introduction

Since the approval of SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> it is possible to reference a function by its argument names using the foo(arg:) syntax but there is no way to reference a zero-parameter function. foo currently references all methods with base name foo. If there are multiple methods with this base name, one has to disambiguate the referenced function by its type using as.

This proposal changes the behaviour of foo to always reference a zero-parameter function. To reference a function with more parameters, the argument labels have to be explicitly named (e.g. foo(arg:)).

Originally, the proposal sought to introduce the new syntax foo(_) to reference an overloaded function with zero parameters, but was discarded based on the discussion on swift-evolution <http://thread.gmane.org/gmane.comp.lang.swift.evolution/16150>.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#motivation>Motivation

Consider the following example

class Bar {
  func foo() {
  }

  func foo(arg: Int) {
  }
}
You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no syntax to reference foo() without using disambiguation by type Bar.foo as () -> Void. We believe this is a major hole in the current disambiguation syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#proposed-solution>Proposed solution

We propose that Bar.foo only references methods with no parameters just as Bar.foo(arg:) references the methods with one argument named arg.

This is a breaking change since Bar.foo currently refers to all methods with base name foo.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#detailed-design>Detailed design

The existing syntax Bar.foo is reinterpreted to not reference any method on Bar with base name foo but to only reference functions named foo that take no parameters.

If two overloads with zero-parameters exist with different return types, disambiguation has still to be done via as just like with the foo(arg:) syntax.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#impact-on-existing-code>Impact on existing code

Existing code that uses Bar.foo to reference methods with parameters needs to be changed. We believe this will effect many developers, so a fix-it would be essential.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#possible-issues>Possible issues

Bar.foo may be mistaken for a reference to a property, since all other references to functions will contain parenthesis if this proposal is accepted.

Most functions are not overloaded and using the base name only offers a shorthand way to reference these functions. If this proposal is accepted, this shorthand is no longer available for methods with parameters.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternatives-considered>Alternatives considered

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-1-barfoo-inside-selector>Alternative 1: Bar.foo() inside #selector

Let Bar.foo() refer to the zero-parameter function only inside #selector as it was proposed by Doug Gregor here <https://github.com/apple/swift-evolution/pull/280#discussion_r61849122>. This requires the proposal to disallow arbitrary expressions in #selector (GitHub-Link <https://github.com/ahoppen/swift-evolution/blob/arbitrary-expressions-in-selectors/proposals/0000-arbitrary-expressions-in-selectors.md>) to be approved. Issues we see are:

This gives the illusion that foo is actually called which it isn't
It doesn't solve the issue of referencing a zero-parameter function in arbitrary expressions somewhere else in code.

<https://github.com/ahoppen/swift-evolution/tree/reference-zero-param-func#alternative-2-barfoo_>Alternative 2: Bar.foo(_)

The original idea of using Bar.foo(_) to refer to the zero-parameter method was discarded after discussion on the mailing list because of the following reasons:

It is only a single typo away from Bar.foo(_:slight_smile: which references the method with one unnamed argument
In argument lists _ implies the presence of an unnamed parameter, while _ in Bar.foo(_) would mark the absence of a any parameters.

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


(David Sweeris) #16

What about <name>:<argument list>? You could reference "foo()" as "foo:()", "foo(arg: T)" as "foo:(arg:)", and the property "foo" as "foo:".

- Dave Sweeris

···

On May 12, 2016, at 16:40, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

Since there doesn’t seem to be much support for the proposal, I’ll drop it and incorporate Alternative 1 into the #selector proposal like Doug suggested.

– Alex

On 12 May 2016, at 20:52, Douglas Gregor <dgregor@apple.com> wrote:

On May 6, 2016, at 12:34 AM, Alex Hoppen via swift-evolution <swift-evolution@swift.org> wrote:

Thanks for your feedback so far. Based on the discussion, I have updated the proposal to let `foo` refer to the zero-parameter function instead of `foo(_)`.

The updated proposal is also available on GitHub: https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/0000-refernce-zero-param-func.md.

Again comments would be greatly appreciated.

General comment: now that this proposal has pivoted to always requiring the argument labels when referencing a function, the title and introduction are misleading. This is a *much* larger change than Alternative 1 or Alternative 2, and is now source-breaking.

(Personally, I still think “Alternative 1” is the right answer)

  - Doug

– Alex

Referencing zero-parameter functions
Proposal: SE-NNNN
Author(s): Alex Hoppen, Pyry Jahkola
Status: Draft
Review manager: TBD
Introduction

Since the approval of SE-0021 it is possible to reference a function by its argument names using the foo(arg:) syntax but there is no way to reference a zero-parameter function. foo currently references all methods with base name foo. If there are multiple methods with this base name, one has to disambiguate the referenced function by its type using as.

This proposal changes the behaviour of foo to always reference a zero-parameter function. To reference a function with more parameters, the argument labels have to be explicitly named (e.g. foo(arg:)).

Originally, the proposal sought to introduce the new syntax foo(_) to reference an overloaded function with zero parameters, but was discarded based on the discussion on swift-evolution.

Motivation

Consider the following example

class Bar {
  func foo() {
  }

  func foo(arg: Int) {
  }
}
You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no syntax to reference foo() without using disambiguation by type Bar.foo as () -> Void. We believe this is a major hole in the current disambiguation syntax.

Proposed solution

We propose that Bar.foo only references methods with no parameters just as Bar.foo(arg:) references the methods with one argument named arg.

This is a breaking change since Bar.foo currently refers to all methods with base name foo.

Detailed design

The existing syntax Bar.foo is reinterpreted to not reference any method on Bar with base name foo but to only reference functions named foo that take no parameters.

If two overloads with zero-parameters exist with different return types, disambiguation has still to be done via as just like with the foo(arg:) syntax.

Impact on existing code

Existing code that uses Bar.foo to reference methods with parameters needs to be changed. We believe this will effect many developers, so a fix-it would be essential.

Possible issues

Bar.foo may be mistaken for a reference to a property, since all other references to functions will contain parenthesis if this proposal is accepted.

Most functions are not overloaded and using the base name only offers a shorthand way to reference these functions. If this proposal is accepted, this shorthand is no longer available for methods with parameters.

Alternatives considered

Alternative 1: Bar.foo() inside #selector

Let Bar.foo() refer to the zero-parameter function only inside #selector as it was proposed by Doug Gregor here. This requires the proposal to disallow arbitrary expressions in #selector (GitHub-Link) to be approved. Issues we see are:

This gives the illusion that foo is actually called which it isn't
It doesn't solve the issue of referencing a zero-parameter function in arbitrary expressions somewhere else in code.
Alternative 2: Bar.foo(_)

The original idea of using Bar.foo(_) to refer to the zero-parameter method was discarded after discussion on the mailing list because of the following reasons:

It is only a single typo away from Bar.foo(_:slight_smile: which references the method with one unnamed argument
In argument lists _ implies the presence of an unnamed parameter, while _ in Bar.foo(_) would mark the absence of a any parameters.

_______________________________________________
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