Agreed. That would only allow to disambiguate call with unused result, but would not solve this problem. Jordan pointed at it. It would be consistent therefore to leave @discardableResult functions with usual non-Void functions.
- Anton 2016-04-27 12:01 GMT+03:00 Andrew Bennett <[email protected]>: > I'm happy to add `@unusedResult`, with a little more discussion. I'm not > sure when it would actually be used though. > > I'm not sure if you can define both of these functions: > > @unusedResult func example() -> Int > func example() -> Int > > Either way, a method with @unusedResult should probably have a different > name to one without. > > You can define both of these functions: > > @unusedResult func example() -> Int > func example() -> String > > However, if the methods return different non-void values they should > probably have different names. > > > On Tue, Apr 26, 2016 at 11:57 PM, Антон Жилин <[email protected]> > wrote: > >> +1 >> >> > Also, technically we can assign a value to Void function >> This proposal will not disallow that. Just non-Void functions will be >> preferred when result is used. >> >> array.sort(..) // mutating >> let array2 = array.sort(..) // non-mutating, instead of array.sorted() >> >> I think, that's actually the best solution to mutating / non-mutating >> convention! >> >> Andrew, why not generalize this proposal to functions with @unusedResult? >> >> In terms of "precedence" when result is used: >> Non-Void > @unusedResult > Void (+warning) >> >> When unused: >> Void > @unusedResult > Non-Void (+warning) >> >> - Anton >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
