The idea is that the writer of the function is the one who can decide whether
or not the result of their function can be safely ignored. Imagine you wrote a
function in Swift:
func times(x: Int, y: Int) -> Int {
return x * y;
}
At the point of writing this function (though it may be a trivial example), you
know that any code which ignores the return value is doing something wrong.
OTOH, in the case of a method like pop(), you might have:
func pop() -> T {
let tmp: T = stack[top]
top -= 1
return tmp
}
Here, the writer of this method knows that sometimes the method may be called
without needing to use the return value. The only case in which a return value
might need to be ignored is in a function or method which has some sort of side
effect. The writer of the function knows whether or not a side effect exists,
so it is safe to allow them to annotate whether or not a return value can be
ignored.
FKL
> On Dec 19, 2015, at 3:04 AM, Kenny Leung via swift-evolution
> <[email protected]> wrote:
>
> Hi All.
>
> Being naive here (also very difficult to say this clearly and succinctly),
> but why is this the choice of the writer of the function rather than the
> person using the function?
>
> That is, I would think that if I were worried about unused return results in
> my code, I would have some kind of flag on the client side, and not on the
> provider side.
>
> Does this question make any sense?
>
> -Kenny
>
>
>> On Dec 10, 2015, at 2:58 PM, Adrian Kashivskyy via swift-evolution
>> <[email protected]> wrote:
>>
>> I think non-void functions should warn about their return value being unused
>> by default, thus eliminating the need to attribute them with
>> @warn_unused_result.
>>
>> Motivation
>>
>> It is a rare case for a result of a function to be unused – and most often
>> it's caused by programmer having too little knowledge of the API. This, in
>> my opinion, is a reasonable area of improvement for the compiler.
>>
>> I also noticed that many of stdlib's functions are marked with this
>> attribute, which supports my point of this being the default behavior.
>>
>> Example code
>>
>> The following should be default behavior:
>>
>>> func square(x: Int) -> Int { return x * x }
>>> square(2) // warning: result of call to 'square' unused
>>
>> Currently, unless annotated by @warn_unused_result, the compiler will not
>> trigger any warnings.
>>
>> Supporting old behavior
>>
>> If, sometimes, it is okay to not use the result, an opposite
>> @suppress_unused_result attribute could be used instead.
>>
>>> @suppress_unused_result func square(x: Int) -> Int { return x * x }
>>> square(2) // no warning
>>
>> Impact on existing code
>>
>> The existing bare @warn_unused_result attributes will become redundant and
>> can be easily removed by migrator. However, if an existing attribute uses
>> message or mutable_variant argument, it may be left intact, since it
>> provides non-obvious informational value.
>>
>> Implementing the above proposal would definitely make the code clearer and
>> intentional, without compromising any major use cases.
>>
>> I would be happy to hear your thought on this.
>>
>>
>> Regards,
>> Adrian Kashivskyy
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
