On 22.02.2017 22:47, Haravikk wrote:
On 22 Feb 2017, at 15:38, Vladimir.S <[email protected]
<mailto:[email protected]>> 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! 😄
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
