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

[Brent Royal-Gordon]

> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
> 
> There were some opinions on Slack that we should simply change `foo` so that it can *only* refer to the nullary version.

I think this is the right solution. Eventually we want to get to the point where parameter labels are part of a compound name; at that point, it'd be natural for a zero-argument function to just have its name be the base name.

> That'd be a source-breaking change,

We can always support looking up members by base name only as an unprincipled shorthand. (But to tell the truth, I'd prefer to just break them.)

> 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?


The simple version is illegal:

	Welcome to Apple Swift version 3.1 (swiftlang-802.0.41 clang-802.0.36). Type :help for assistance.
	  1> struct X { var x: Int; func x() {} }
	error: repl.swift:1:29: error: invalid redeclaration of 'x()'
	struct X { var x: Int; func x() {} }
	                            ^
	
	repl.swift:1:16: note: 'x' previously declared here
	struct X { var x: Int; func x() {} }
	               ^

I have a sneaking suspicion there actually *are* circumstances where it's possible—but I think there probably shouldn't be.

Of the main options discussed—`foo(_)` vs `foo(:)`—I think the underscore is more accurate. It does conflict with pattern matching syntax, but I don't think you can match a (0-ary) function value against anything anyway, so I don't think that matters in practice.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170408/742fa2f8/attachment.html>