[swift-evolution] [Pitch] Allow trailing argument labels

Vladimir.S svabox at gmail.com
Wed Feb 22 15:22:49 CST 2017


On 22.02.2017 22:47, Haravikk wrote:
>
>> On 22 Feb 2017, at 15:38, Vladimir.S <svabox at gmail.com
>> <mailto:svabox at gmail.com>> wrote:
>> Do I understand correctly, that the proposed solution is some kind of
>> sugar to not have separate method named like 'addingWithReportingOverflow' ?
>
> Basically yes; the discussion came up briefly during protocol oriented
> integers where this is quite common, especially with added methods for
> handling double-width operations and such as well.
>
>> In any case IMO such argument label should have special syntax on caller
>> site.. don't know, probably:
>>
>> let resultWithOverflow = a.adding(b, :reportingOverflow)
>>
>> probably with the same declaration:
>> func adding(_ other:Self, :reportingOverflow) -> (Self, Bool)
>
> Huh, that could be a great alternative! It would solve the ambiguity issues
> completely and allow for even single argument cases (if someone wanted to
> use those).
> Any preferences on how to specify these arguments? e.g- just declare them
> void, attribute or something else?

Sorry, not sure I understand the question. I think about such feature as 
Swift's syntax extension, when :reportingOverflow treated as .. a part of 
method name, as it is actually not an argument. And we shouldn't even be 
able to "touch" 'reportingOverflow' inside the func as it is not an 
argument but a part of function name.

Another alternative I can think of is such:
let resultWithOverflow = a.adding(b):reportingOverflow
func adding(_ other:Self):reportingOverflow -> (Self, Bool)
but in this case ':' looks in caller site like some operation on adding() 
result.

And actually I'm not sure that feature(actually the sugar) worth the added 
complexity.

>
> Also apologies to Patrick, I seem to be leading his discussion, I really
> should get some work done! 😄


More information about the swift-evolution mailing list