[swift-evolution] Make non-void functions @warn_unused_result by default

[Kenny Leung]

Hi Frederick.

Thanks for the explanation. This makes sense.

Since I’m on the side of simplicity and deliberateness - I like the fact that Swift makes you say, “I meant to do that” - I vote for making @warn_unused_result the default with no opposite-sense replacement. You would have to do _ = blah() to tell the reader you know that there’s a return value and you don’t care.

-Kenny


> On Dec 19, 2015, at 12:13 AM, Frederick Kellison-Linn via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution