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 > <[email protected]> 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 >> <[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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
