Re: [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

[Joe Groff via swift-evolution]

> On Mar 24, 2017, at 3:57 PM, Peter Dillinger via swift-evolution 
>  wrote:
> 
> I recently criticized Swift 3 for allowing many expressions with no side 
> effects as statements, in this blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "that expression").  I've seen some related discussion such as 
> "Make non-void functions @warn_unused_result by default", but not quite this.
> 
> For emphasis, let me include a real example (from open-source software, 
> simplified) of defective JavaScript code that happens to be legal Swift as 
> well:
> 
> var html = "" +
>  "" +
>  trs
>  "" +
>  "";
> 
> DEFECT SPOILER:   (There is a 
> missing '+')
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.
> 
> I have not formulated this into a detailed proposal, but I suspect that 
> because of Swift's pervasive overloading, implicit constructor calls, etc., 
> it would involve introducing a new @error_unused_result annotation and using 
> that in many places in the standard library.  I also suggest that user 
> overloads of traditionally non-side-effecting operators, as well as 
> non-mutating struct methods, be @error_unused_result by default, or perhaps 
> by mandate.  Our experience also suggests this @error_unused_result feature 
> could also be useful for ordinary methods of classes, as we find a number of 
> defects where a method call is expecting a side effect but there is none, 
> because the method is only useful for its return value.

In the Swift 3 timeframe, we adopted pretty much exactly these rules, albeit 
making value-producing operations *warn* by default instead of error. There's 
already a @discardableResult attribute that you can apply to declarations whose 
result is intended to be discardable. The philosophy of warnings vs errors is 
being discussed in your thread on unreachable code, so I don't think it needs 
to be reiterated here.

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

[Peter Dillinger via swift-evolution]

> If I copy/paste your code (and add a definition for “trs”), Swift already 
> gives a warning: ... What version of Swift are you using?

The first word of my subject is “disallowing” not “warning.”  And I wrote, and 
you quoted, the following about compiler warnings:

>> Part of my argument is that people commonly ignore compiler warnings.  We 
>> see lots of defective
>> code that would be (or is) caught by compiler warnings but people don't pay 
>> attention.

I'm not sure what your point was, but I consider the fact that the compiler 
already has a proof-of-concept implementation of my proposal as a positive, 
risk- and expense-reducing aspect of the proposal.

-- 
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

[David Sweeris via swift-evolution]

> On Mar 24, 2017, at 3:57 PM, Peter Dillinger via swift-evolution 
>  wrote:
> 
> I recently criticized Swift 3 for allowing many expressions with no side 
> effects as statements, in this blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "that expression").  I've seen some related discussion such as 
> "Make non-void functions @warn_unused_result by default", but not quite this.
> 
> For emphasis, let me include a real example (from open-source software, 
> simplified) of defective JavaScript code that happens to be legal Swift as 
> well:
> 
> var html = "" +
>  "" +
>  trs
>  "" +
>  "";
> 
> DEFECT SPOILER:   (There is a 
> missing '+')
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.
> 
> I have not formulated this into a detailed proposal, but I suspect that 
> because of Swift's pervasive overloading, implicit constructor calls, etc., 
> it would involve introducing a new @error_unused_result annotation and using 
> that in many places in the standard library.  I also suggest that user 
> overloads of traditionally non-side-effecting operators, as well as 
> non-mutating struct methods, be @error_unused_result by default, or perhaps 
> by mandate.  Our experience also suggests this @error_unused_result feature 
> could also be useful for ordinary methods of classes, as we find a number of 
> defects where a method call is expecting a side effect but there is none, 
> because the method is only useful for its return value.
> 
> If you would like to see more defect examples from open-source software 
> (other languages for the moment), I should be able to dig up some more.


If I copy/paste your code (and add a definition for “trs”), Swift already gives 
a warning:
let trs = "trs"
var html = "" +
  "" +
trs
"" + // Warning: Result of operator '+' is unused
"";

What version of Swift are you using? IIRC, it didn’t start doing that until 
Swift 3.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

[Peter Dillinger via swift-evolution]

I recently criticized Swift 3 for allowing many expressions with no side 
effects as statements, in this blog post: 
https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
 (search for "that expression").  I've seen some related discussion such as 
"Make non-void functions @warn_unused_result by default", but not quite this.

For emphasis, let me include a real example (from open-source software, 
simplified) of defective JavaScript code that happens to be legal Swift as well:

var html = "" +
  "" +
  trs
  "" +
  "";

DEFECT SPOILER:   (There is a 
missing '+')

Part of my argument is that people commonly ignore compiler warnings.  We see 
lots of defective code that would be (or is) caught by compiler warnings but 
people don't pay attention.

I have not formulated this into a detailed proposal, but I suspect that because 
of Swift's pervasive overloading, implicit constructor calls, etc., it would 
involve introducing a new @error_unused_result annotation and using that in 
many places in the standard library.  I also suggest that user overloads of 
traditionally non-side-effecting operators, as well as non-mutating struct 
methods, be @error_unused_result by default, or perhaps by mandate.  Our 
experience also suggests this @error_unused_result feature could also be useful 
for ordinary methods of classes, as we find a number of defects where a method 
call is expecting a side effect but there is none, because the method is only 
useful for its return value.

If you would like to see more defect examples from open-source software (other 
languages for the moment), I should be able to dig up some more.

Thanks

--
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution