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

[Derrick Ho]

foo(_) seems better. A colon would imply there is an argument of which
there is none.
On Wed, Feb 22, 2017 at 4:52 AM Patrick Pijnappel via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm personally in favor of foo(_), as the number of colons currently
> lines up directly with the number of arguments, and it'd be good to keep it
> that way.
>
> In general though I'm very in favor of requiring the parentheses, as the
> ambiguity between unparenthesized references to functions and properties
> can be quite confusing/annoying.
>
> On Wed, Feb 22, 2017 at 6:35 PM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> On 22 Feb 2017, at 08:05, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Evolutioniers,
>
> *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
> functions.*
>
> Advantages:
> - the colon marks a clear similarity to the foo(bar:) form when argument
> labels are present.
> - cutely parallels the empty dictionary literal, [:].
>
> Disadvantages:
> - violates intuition about one-colon-per-argument.
>
>
> This is a big disadvantage for me and will potentially be very surprising
> for newcomers.
>
> - 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).
>
>
> This is my favorite syntax so far.
>
> Looking forward to everyone's bikeshed color ideas,
> Jacob
>
> _______________________________________________
> 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/20170222/c4f4aa43/attachment.html>