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

Andrew Bennett cacoyi at gmail.com
Thu Dec 17 17:46:56 CST 2015


I like this proposal, I'd also like it if using array.append warned you
that you didn't actually call it (maybe it does in swift 2.2).

My only cornern is whether the following is ambiguous or not:
    func pop() {}
    func pop() -> Int { return 1 }
    pop()

In my opinion that should call the first pop. Without the first pop that
would probably have a warning, yet it is a common case to pop and ignore
the value. I know I could do this:

let _ = pop()

However that's ugly just to remove the warning.

I agree with Tino, returning Self should probably not have a warning.

On Friday, 18 December 2015, Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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.
>
> I don't think this is a real life problem. When you have a class with
> something like "append" that doesn't change the receiver but returns a new
> object, it could be a valuable hint, but I don't like systems which assume
> that their users don't know what they are doing; and if this is actually
> the case, you are fighting a tough battle where a little warning wont help.
>
> Please also note that ignoring a non-void return value can be absolutely
> ok in many situations: One example is returning self instead of useless
> void, which allows to build fluent interfaces - just because Cocoa didn't
> adopt the concept of method chaining from Smalltalk, it is still a
> interesting pattern which is used by other frameworks.
>
> Imho warnings should be reserved for things that can be dangerous, and not
> to educate programmers...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/58ea98db/attachment.html>


More information about the swift-evolution mailing list