[swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Jacob Bandes-Storch jtbandes at gmail.com
Wed Feb 22 01:05:21 CST 2017


*Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
disambiguate references to functions. (You might've used it inside a
#selector expression.) But there's currently no compound name for a
function with no arguments.

    func foo() {}  // no compound syntax for this one :(
    func foo(_ bar: Int) {}  // foo(_:)
    func foo(bar: Int) {}  // foo(bar:)
    func foo(bar: String, baz: Double) {}  // foo(bar:baz:)

Given these four functions, only the first one has no compound name syntax.
And the simple reference "let myfn = foo" is ambiguous because it could
refer to any of the four. A workaround is to specify a contextual type,
e.g. "let myfn = foo as () -> Void".

I filed SR-3550 <https://bugs.swift.org/browse/SR-3550> for this a while
ago, and there was some discussion in JIRA about it. I'd like to continue
exploring solutions here and then write up a formal proposal.

To kick off the discussion, *I'd like to propose foo(:) for nullary

- the colon marks a clear similarity to the foo(bar:) form when argument
labels are present.
- cutely parallels the empty dictionary literal, [:].

- violates intuition about one-colon-per-argument.
- the parallel between #selector(foo(:)) and @selector(foo) is not quite as
obvious as between #selector(foo(_:)) and @selector(foo:).

For the sake of discussion, another option would be *foo(_)*. This was my
original choice, and I like that the number of colons matches the number of
parameters. However, it's a little less obvious as a function reference. It
would preclude _ from acting as an actual identifier, and might conflict
with pattern-matching syntax (although it appears functions can't be
compared with ~= anyway).

Looking forward to everyone's bikeshed color ideas,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/baf09719/attachment.html>

More information about the swift-evolution mailing list