[swift-evolution] Proposal Idea: Use of == outside of comparisons should be treated as an error.

Andrew Bennett cacoyi at gmail.com
Tue Jan 12 15:01:31 CST 2016


I'm +1 on @warn_unused_result, does that need a proposal or is a PR
sufficient?

On Tue, Jan 12, 2016 at 7:45 AM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jan 11, 2016, at 12:39 PM, Jared Sinclair via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Consider the following:
>
> protocol Updatable {
>     func update(state: Bool)
> }
>
> class Thing: Updatable {
>     private var enabled = false
>
>     func update(state: Bool) {
>         self.enabled == state
>     }
> }
>
> The obvious intention is to set self.enabled to the incoming value of
> state. However, it’s easy to accidentally type a second equals sign. The
> effect of this typo is self.enabled is never updated, leading to a
> run-time bug that could be difficult to diagnose.
>
> This typo doesn’t generate any errors or warnings. I can’t think of a
> valid reason to use the equals function outside of comparisons. If the
> compiler instead treated this typo as an error, the mistake would be
> trivial to identify and fix:
>
> protocol Updatable {
>     func update(state: Bool)
> }
>
> class Thing: Updatable {
>     private var enabled = false
>
>     func update(state: Bool) {
>         self.enabled == state // Error: `==` may not be used outside of
> comparisons
>     }
> }
>
>
> If it isn't already, the implementation of `==` ought to be marked with
> the `@warn_unused_result` attribute, which will give you a warning if the
> result is ignored. We're discussing making warn_unused_result the default
> behavior in another thread.
>
> -Joe
>
>
> _______________________________________________
> 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/20160113/fac6b7cb/attachment.html>


More information about the swift-evolution mailing list