> On Apr 6, 2017, at 7:02 AM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously > distinguished from foo(), I think that would be the only logical result.
Agree. It seem like this would fit nicely into the revision of SE-0042 that Doug mentioned. > > > On Thu, Apr 6, 2017 at 00:40 Jacob Bandes-Storch via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Now that escaping with \ has been proposed for KeyPaths, this makes me wonder > whether it would be appropriate to use "\foo()" rather than "foo(_)"/"foo(:)" > ? It still feels a bit strange, as \foo() looks like escaping the result of > a call. > > > On Sat, Feb 25, 2017 at 1:43 PM, David Hart <[email protected] > <mailto:[email protected]>> wrote: > >> On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I don't have a good answer for this, but I'll vote against 'foo(:)' because >> that's what a lot of people think the name of 'foo(_:)' should be. I'd >> rather be able to offer fix-its for that even when you have both 'foo()' and >> 'foo(_:)' defined. I'd rather go with 'foo(_)' despite the tiny ambiguity in >> pattern contexts. >> >> (I'm personally in favor of killing unapplied function references altogether >> in favor of closures, on the grounds that they are overly terse, make >> type-checking more complicated, and often lead to retain cycles. Then we'd >> only need this for #selector, and it's perfectly unambiguous to use 'foo()' >> there. But I wasn't planning to fight that particular battle now, and it is >> rather annoying to require the 'as' in the meantime.) > > It is potentially going to be hard to fight that battle. I think a lot of > functional/Haskell people love them and would be sad to see them go away (I > plead guilty). But it isn’t a well known part of the language so I don’t > think the general community would miss it. > >> Jordan >> >> >>> On Feb 21, 2017, at 23:05, Jacob Bandes-Storch <[email protected] >>> <mailto:[email protected]>> 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. >>> - 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, >>> Jacob >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
