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

[Jacob Bandes-Storch]

Not that it seems highly contested, but +1 from me as well.

Jacob

On Fri, Dec 18, 2015 at 2:01 PM, Janosch Hildebrand via swift-evolution <
swift-evolution at swift.org> wrote:

> I am also strongly in favor of this proposal.
>
> There are probably enough valid use cases for a @suppress_unused_warning but
> personally I don't think pop() is a great example.
>
> I think a second method à la dropFirst/Last/... that returns Void would
> be better at communicating intent and allows pop() to retain the warning.
>
> - Janosch
>
> On 18 Dec 2015, at 21:48, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I vote +1 in favor of making warn_unused_result the default. It's simple,
> elegant, logical, functional, and will reduce stdlib clutter.
>
> As for replacing it? Although I'd probably be okay with
> suppress_unused_warning, please consider optional
> hey_no_worries_mate_on_unused, unused_is_mellow, or dont_harsh_my_unused.
> Supporting _ = pop() without further warning is icing on the cake, as it
> enables the behavior to be established at either the API or consuming end.
>
> -- E
>
> On Dec 18, 2015, at 1:25 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Dec 18, 2015, at 3:47 AM, Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> _ = pop()
>
>
> Now that's what I'd call ugly - I vote against everything that forces me
> to use more underscores ;-)
>
>
> “pop()” is an example of the comparatively-rare method that one might want
> to annotate to avoid the warning: the side-effect is useful even if you’re
> dropping the result.  We’re only talking about making warn_unused_result
> the *default*, not making it the only option.
>
> -Dave
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/d6e3c47d/attachment.html>