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@swift.org> wrote: > > On 22 Feb 2017, at 15:38, Vladimir.S <sva...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution