[swift-evolution] Make non-void functions @warn_unused_result by default
Jens Persson
jens at bitcycle.com
Thu Dec 17 19:24:18 CST 2015
> let _ = pop()
> However that's ugly just to remove the warning.
As noted previously, the let is not necessary:
_ = pop()
On Fri, Dec 18, 2015 at 12:46 AM, Andrew Bennett via swift-evolution <
swift-evolution at swift.org> wrote:
> 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...
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens at bitcycle.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/ac423f9e/attachment.html>
More information about the swift-evolution
mailing list