[swift-evolution] [Pitch] Allow trailing argument labels
patrickpijnappel at gmail.com
Wed Feb 22 15:25:12 CST 2017
To summarize, there's one ambiguous case we'd need to resolve:
func foo(_ x: Int, reportingOverflow)
func foo(_ x: Int, _ reportingOverflow: Bool)
let reportingOverflow = true
foo(5, reportingOverflow) // Ambiguous
One solution is to make trailing argument labels syntactic sugar for a
trailing void argument.
That would allow breaking ambiguity by specifying it explicitly:
foo(5, reportingOverflow: ())
A related issue is the call-site ambiguity for the reader (less of a
problem if Xcode highlighted argument labels).
On Thu, Feb 23, 2017 at 6:47 AM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:
> On 22 Feb 2017, at 15:38, Vladimir.S <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?
> Also apologies to Patrick, I seem to be leading his discussion, I really
> should get some work done! 😄
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution