> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
