> On 22 Feb 2017, at 10:24, Patrick Pijnappel via swift-evolution
> <[email protected]> wrote:
>
> I'd like to discuss allowing a trailing 'argument label' without an actual
> argument:
>
> func adding(_ other: Self, reportingOverflow) -> … // Actual case in SE-104
> where this came up
> func tableView(_ tableView: UITableView, numberOfSections) -> Int //
> Referenced as tableView(_:numberOfSections)
>
> As illustrated above, the way we reference functions extends very naturally
> to include these.
>
> This would be very useful for several cases:
> • Delegate methods, which currently all start with the same prefix, except
> for some odd cases that really actually just needed a trailing argument label.
> • Cases where the function is a more specialized version of one with the same
> name, but can't use a flag because the return type is different (e.g.
> reportingOverflow), or the extra flag check is just undesirable. The standard
> library now uses some workarounds to achieve this (e.g. having a trailing
> argument of type void).
> • Function names that just work more naturally with some additional words
> after the last argument. If we allow trailing argument labels, you can form
> any sentence, rounding out the syntax.
>
> Overall, I think this could be the final missing piece to complete Swift's
> functions-as-sentences approach.
I'm a +1 for this.
I think the best way to define it though would be to use Void arguments, and
simply eliminate the need to add :() to call them if they are trailing. We
should however retain the ability to add the colon for disambiguation.
Some examples to illustrate:
struct Foo { func adding(_ other:Foo, reportingOverflow:Void) { … } }
var a = Foo(), b = Foo()
a.adding(b, reportingOverflow) // Trailing Void argument doesn't
require a value, so :() can be omitted
let reportingOverflow = "I don't know why I defined this"
a.adding(b, reportingOverflow) // This is now ambiguous thanks to my
stupidly named variable
a.adding(b, reportingOverflow:) // However, this isn't, thanks to the
colon clarifying that it's a label
It's possible the feature doesn't have to be restricted to only trailing
arguments; the key is the ambiguity due to variable names and/or function
selection. For example:
struct Foo { func example(foo:Void) -> String { … }}
var foo = Foo()
foo.example(foo) // What did I mean here?
let result = foo.example(foo:) // This looks like I might be trying to
select a function, rather than call it
So it's possible it could be allowed for any function that has at least one
non-Void argument?
I think to really seal the deal it would be nice if Xcode would highlight
argument labels differently, as that would make it clearer to user's what
something is at a glance, but that's a separate issue.
Just some thoughts; I do prefer this to using single case enums just to create
a different method signature. Labels are definitely the right way to do this.
The main thing for me is that I think we should keep the requirement to specify
the type in the function declaration as Void, just for clarity._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
