Incidentally--and I suppose I will have to repeat myself somewhere else in the likely case that this is not seen by the people who are designing this feature--using the sigil syntax `\foo()` nicely solves the nullary function problem, but we get another ambiguity with the introduction of key paths and function references using the same syntax:
Currently, it is possible to have a member `var foo` and another `func foo(bar:baz:)` in the same type. There is no real necessity to forbid that, though I doubt it would break too many people's code. (I did, however, once suggest naming `FloatingPoint.ulpOfOne` to simply `FloatingPoint.ulp`, which would have taken advantage of this rule.) In such a scenario, `\foo` becomes ambiguous. It would be sufficient to say that in such scenarios `\foo` is always interpreted as referring to `var foo`, while `\foo(bar:baz:)` becomes the only way of writing a reference to the function. On Thu, Apr 6, 2017 at 9:59 AM, Ricardo Parada <[email protected]> wrote: > Agree. > > > On Apr 6, 2017, at 8: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. > > > On Thu, Apr 6, 2017 at 00:40 Jacob Bandes-Storch via swift-evolution < > [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]> wrote: >> >> >> On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution < >> [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]> >> 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] >> 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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
