Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-3550] Compound name syntax for functions with no params #46138

Open
jtbandes opened this issue Jan 5, 2017 · 11 comments
Open

[SR-3550] Compound name syntax for functions with no params #46138

jtbandes opened this issue Jan 5, 2017 · 11 comments
Labels
compiler The Swift compiler in itself feature A feature request or implementation good first issue Good for newcomers improvement parser Area → compiler: The legacy C++ parser swift evolution proposal needed Flag → feature: A feature that warrants a Swift evolution proposal type checker Area → compiler: Semantic analysis

Comments

@jtbandes
Copy link
Collaborator

jtbandes commented Jan 5, 2017

Previous ID SR-3550
Radar None
Original Reporter @jtbandes
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, StarterProposal
Assignee None
Priority Medium

md5: 9e54c0bcc3910a9a4c3dc549a118933b

relates to:

  • SR-1408 NSArray indexesOfObjectsPassingTest cannot be called in Swift 3

Issue Description:

The "compound name" of a function can be used to resolve ambiguities with argument labels, e.g. foo(x:) or foo(_:). However, there's no such shortcut to specify an overload that has no arguments. A workaround is to use its type with as:

import Foundation
class C: NSObject {
    func foo() {}
    func foo(x: Int) {}
}

#selector(C.foo)  // error: ambiguous use of 'foo'
#selector(C.foo(x:))  // resolve ambiguity with compound name
#selector(C.foo as (C) -> () -> ())  // resolve ambiguity by specifying type

But it'd be nice to have some way of doing this without specifying the type. Perhaps foo(_) (for symmetry with foo(_:))?
@slavapestov
Copy link
Member

Huh. I thought f(🙂 was supported, but it's not.

@jtbandes
Copy link
Collaborator Author

jtbandes commented Jan 5, 2017

Let's see if I can double-escape this — you can use 🙂

@belkadan
Copy link
Contributor

belkadan commented Jan 5, 2017

There was discussion about this but I can't remember where it landed. The "correct" name is foo() but outside of #selector that would be ambiguous.

@jtbandes
Copy link
Collaborator Author

jtbandes commented Jan 5, 2017

Ambiguous? I think it would be unambiguously a function call 🙂

@belkadan
Copy link
Contributor

belkadan commented Jan 6, 2017

@DougGregor probably remembers where we ended up in this discussion.

@DougGregor
Copy link
Member

I thought we left it at "we don't have a good way to spell this, but it would be nice".

@xwu
Copy link
Collaborator

xwu commented Jan 31, 2017

Might I suggest, for parallels to `[:]` being an empty dictionary, `foo( : )`? It avoids `_` implying the presence of something discarded.

@jtbandes
Copy link
Collaborator Author

The issue I have with foo(:) is that the presence of : in all other spellings implies there is an argument...

@xwu
Copy link
Collaborator

xwu commented Jan 31, 2017

...not in `[:]`?

My thinking was, we've already got a precedent. `[]` means something other than an empty dictionary. Given that `["someKey": "someValue"]` is how a dictionary with one key-value pair is spelled, `[:]` is chosen to represent a dictionary with zero key-value pairs.

By analogy, we've got a situation where `()` means something else (i.e. it invokes the function). Given that `foo(label: )` is how a function with one parameter is spelled, `foo( : )` can be how a function with zero parameters is spelled. It ain't perfect, but IMO it's not bad.

Edit: how did you get this fudging thing to let you write () with : in it?

@jtbandes
Copy link
Collaborator Author

Backslash before the colon. Code snippets are double-curly-braces.

I'm pretty used to [:] by now, although if I were starting over I might be in favor of curly braces for dictionary literals. And I might like [:] less if [someKey:] and [someKey1:someKey2:] had a meaning too. Anyway, your argument is pretty reasonable; after thinking about it more, I think I'd be fine with either foo(_) or foo(:).

@belkadan
Copy link
Contributor

I think if we're inventing new syntax, swift-evolution needs a chance to bikeshed it.

I don't personally like either of these options but I suppose I like foo(:) very slightly better.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added parser Area → compiler: The legacy C++ parser good first issue Good for newcomers feature A feature request or implementation type checker Area → compiler: Semantic analysis swift evolution proposal needed Flag → feature: A feature that warrants a Swift evolution proposal and removed StarterProposal labels Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler The Swift compiler in itself feature A feature request or implementation good first issue Good for newcomers improvement parser Area → compiler: The legacy C++ parser swift evolution proposal needed Flag → feature: A feature that warrants a Swift evolution proposal type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@xwu @jtbandes @slavapestov @belkadan @DougGregor @AnthonyLatsis