[swift-evolution] Disambiguate Return Type With Void

[Антон Жилин]

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 <cacoyi at gmail.com>:

> 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, Антон Жилин <antonyzhilin at gmail.com>
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160427/d03a8cb9/attachment.html>