[swift-evolution] [swift-evolution-announce] [Review] Naming Functions with Argument Labels
kevin at sb.org
Thu Jan 14 02:05:25 CST 2016
On Wed, Jan 13, 2016, at 09:16 AM, Joe Groff wrote:
> * What is your evaluation of the proposal?
I'm tentatively in favor. I think this solves a real problem, and I like
that it's re-using the same syntax that we already use to talk about
functions in documentation and discussions. I'm mildly concerned about
the visual ambiguity, and about the fact that if the parser encounters
`foo.bar(baz: qux` it doesn't know yet if "qux" is supposed to be an
expression (because it's a function call) or just a bare identifier
(because it's a function reference), and it can't know that until it
sees a colon. I'm also mildly concerned that this feature will make it
impossible to ever introduce a single colon as a valid character in an
expression that's not surrounded by delimiters (e.g. dictionary literals
are fine because of the delimiters), but I'm not sure if that's
something we'd ever want to do (note that introducing a double colon,
e.g. ::, is fine because that's not legal in a function reference).
Given that I think the ambiguity can be dealt with, and I don't think
the visual ambiguity is particularly bad, and I'd like to see this
problem have a solution, that's why I'm tentatively in favor of it.
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
I think so, yes.
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
I have not. The languages I can think of that have similar types of
function references don't have infix method names (or don't even support
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
A quick reading.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution