There were some opinions on Slack that we should simply change `foo` so that it can *only* refer to the nullary version.
That'd be a source-breaking change, but I'm also not sure whether it's even solve the problem — is it true you might still have both a function and a variable named foo accessible in the same scope? On Wed, Feb 22, 2017 at 11:48 AM David Sweeris <[email protected]> wrote: > > > On Feb 22, 2017, at 11:05 AM, Matthew Johnson <[email protected]> > wrote: > > > > > >> On Feb 22, 2017, at 12:30 PM, David Sweeris <[email protected]> > wrote: > >> > >> > >>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution < > [email protected]> wrote: > >>> > >>> I like this idea. I think you made the right choice of syntax given > the alternatives considered. To me `foo(_)` and `foo(:)` equally imply > presence of an argument. The former looks like an anonymous (unnamed) > argument and the latter includes the colon which only follows an argument. > Between the two `foo(:)` is the better choice because it doesn’t look like > a pattern as has been pointed out. > >>> > >>> I’m going to do a little brainstorming to try and come up with > something that works and doesn’t imply an argument at all but suspect I’ll > come up empty handed. > >> > >> What about “foo(Void)”? It might be fairly easily confused with > “foo(:Void)”, but in practice, how likely is it for someone to declare both > `foo()` and `foo(_: Void)`? > > > > I almost threw out `foo(Void)` and `foo(Never)` as ideas. There is at > least one problem with these. We will hopefully eventually get rid of the > need to say `.self` in expressions like `Int.self`. If we are able to do > that then `foo(Void)` and `foo(Never)` are syntactically valid function > calls. > > Oh, good point! Hrmm… “foo(#null)”/“foo(#nullary)"? I can’t imagine either > of those would ever be valid function calls, and they get the point across > (the later more than the former, but it’s more to type). I don’t like that > syntax for the name of “shortest” version of the function isn’t shorter > than the syntax of the name for other versions of the function, though. > > - Dave Sweeris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
